The Sprint and the Scrum in simple words
First things first, what is a Sprint?
Sprints are the heartbeat of Scrum, where ideas are turned into value. — The Scrum Guide 2020
The Sprint through the lens of the RUGBY.
The SCRUM methodology is a metaphor for the game of Rugby — Ken Schwaber, “The SCRUM Development Process”
The Sprint is like the Rugby game. The team uses a non-linear, adaptive strategy similar to the Empirical process of Inspecting and Adapting. In the 80-minute time limit(the Sprint length). The cross-functional and self-organizing team continuously adapts to the emerging changes (like changing business needs) and discusses the strategy (like the Scrum events) based on the progress. The team executes under the boundaries of the game (The Scrum Guide).
In the Scrum framework, a Sprint is a fixed timebox available for the team to plan and work on a common goal, and these Sprints may continue as long as the Product emerges. The outcome of each Sprint should be a working product and should add value along with the previous Sprints outcome.
To understand better, let us take an example of building a castle using the Lego building blocks (The Product Goal) in 6 hours (timeline).
The team self organized and decides the strategy to execute adhering to the rules (The Scrum Guide). Say the team decides to have an hour window (the Sprint length) and plans the following:
- The team gathers to understand the product goal and break them into small achievable goals (Refinement).
- The team then plans (Sprint Planning) what to build (Sprint Goal), self-organizes, and works collectively.
- At the end of the one-hour window(the Sprint end), the outcome achieved will be the Increment.
- The team will regroup and review the Increment (Sprint Review) to collect the feedback.
- The team then discusses what can improve (Sprint Retrospective) and repeat.
Basic characteristics of the Sprint:
- Once defined, all the Sprints will have the exact same lifespan (The cadence only changes, in case the team decides).
- A Sprint lives up to a maximum of one month.
- A new Sprint is born on the immediate day the previous expires.
- A Sprint in its lifespan enjoys all the Scrum Events.
Few important factors influencing the Sprint execution:
Please note: Points 2 through 6 are my personal thoughts on what I find important and what has worked for me (Not included in the Scrum Guide).
- Team’s capacity. (mentioned in the Sprint Planning section of the Scrum Guide 2020)
- RAID (Risks / Assumptions / Issues / Dependencies) — External/ Internal.
- External factors influencing the work (eg: Infrastructure Maintenance, Licensing libraries, Privacy Policies, Terms & Conditions etc.)
- Prioritization
- Performance, Security
- Architecture runway (support consistent delivery to achieve business needs) Please refer to my article here to know more on this topic.
Hang on, hang on, hang on!! Maybe this makes sense. Let’s take a look further.
What is an ideal duration of a Sprint?
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
— The Scrum Guide 2020
The Scrum Guide does not provide any recommendation on the Sprint length other than the above mentioned. However, I recommend the team to chose the Sprint length which enables them to deliver the valuable increment(s) within the chosen duration.
Below are my recommendations:
- One week Sprint: Ideal for the teams familiar with the Agile environment, self-organized with a stable velocity, have little or no dependencies, and most importantly capable of producing an Increment as per the Definition of Done in a week.
- Two-week Sprint: It is the most optimal and commonly chosen cadence by most of the teams. The two-week duration provides a fair opportunity to take benefit of all the Scrum events, allows the team to inspect, adapt, and help produce a valuable Increment.
- Two weeks < The Sprint < One Month: A two-week Sprint is Ideal for teams with the complex nature of work, with lack of infrastructure, having huge external dependencies blocking the team, etc. With a Sprint cadence greater than two weeks, the team will have longer feedback loops and lesser opportunities to improve. Thus, restricting the team from taking the leverage of the Scrum framework.
Can the Sprint cadence change?
Scrum Guide 2017 — Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
Once a Sprint starts (say Sprint 1), if the Sprint 1’s length/duration changes, it will be challenging for the team to reevaluate the plan and ensure the Sprint Goal is intact. However, if the team learns that either shortening or extending the cadence (not more than a month) will help produce better value, it is recommended for the team to make that shift for future Sprints.
Who decides the cadence?
The Scrum Guide doesn’t specifically mention who or which role decides or owns the decision on the Sprint length. However, I would recommend the Scrum team to own the decision.
(The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. -The Scrum Guide 2020)
The reason I support the Scrum team to own the decision is because of the following reasons:
a. To ensure successful execution of the Sprint, the Product Owner needs to get the required information from the upcoming Sprints.
b. The Developers should plan to deliver working software at the end of each Sprint and also ensure continuous Inspection and Adaptation.
c. The Scrum Master should be able to help remove impediments for the team and ensure the team is able to take advantage of the Scrum Framework and the Sprint duration is not forcing the team to follow waterfall in the name of Scrum.
Challenges
For an inexperienced team having a lengthier Sprint cadence may make it difficult to envision the increment itself.
Some of the most common challenges include:
- The Product Owner may receive different directions or a change in priorities, which will impact predictability.
- Too many commitments in a single Sprint requires a lot of self-organization within the team (especially when the team has external dependencies)
- Fewer Sprint Reviews can reduce the opportunity for the development team to collaborate with stakeholders and have more deviations on the expectations.
- The team comparatively will have fewer retrospectives meaning, only a few opportunities to Inspect and Adapt.
- Greater risk of uncertainties, assumptions, impediments making it look like a waterfall wrapped in the name of Agile.
Scrum Events
- Sprint planning: Sprint Planning initiates the Sprint.
Timebox: 8 hours for a one-month Sprint and relatively less for shorter Sprints.
Activity: The Scrum team discusses the following:
- Why is this Sprint valuable?
- What can be Done this Sprint?
- How will the chosen work get done?
Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
— The Scrum Guide 2020
- Daily Scrum: As the name suggests, an event that is held every working day of the Sprint.
Timebox: 15 minutes
Activity: The event is for the Developers to inspect the current progress, identify any potential impediments, make the required course correction, and plan the activities for the day. The main focus of the team is the Sprint Goal with the individual responsibilities. The team should decide what works best rather than conform to a specific perspective of running the Daily Scrum.
To reduce complexity, it is held at the same time and place every working day of the Sprint. — The Scrum Guide 2020
Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. — The Scrum Guide 2020
- Sprint Review: Did we do it right? What’s next?
Timebox: 4 hours for a one-month Sprint and relatively less for shorter Sprints.
Activity: The Scrum Team presents the Increment (The demonstration of the outcome that is produced as per the team’s Definition of Done). The Scrum Team along with the stakeholders collaborate and discuss on the outcome vs the product vision. The Sprint Review provides a direction to the Scrum Team on what to build in the future Sprints.
(Please note: The team should ensure the Increment adheres to quality measures, as defined in the Definition of Done)
The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation. — The Scrum Guide 2020
- Sprint Retrospective: Inspect the past and ascertain the future.
Timebox: 3 hours for a one-month Sprint and relatively less for shorter Sprints.
Activity: It is an event for the Scrum Team to focus on the Sprint, analyze what went well and what could have been better), and prepare a concrete action plan to improve that can help the team produce better quality Increments. The event is also a formal opportunity to refine the Define Of Done. Please Note: To enforce quality, the Scrum Guide 2017(under the Sprint Backlog section) stated: The Sprint Backlog includes at least one high priority process improvement identified in the previous Retrospective meeting. However, in the Scrum Guide 2020, the above statement is removed, and I believe the sole intention is to provide flexibility to the Scrum Team(The Scrum Team is best to decide when to bring the process improvements)
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
— The Scrum Guide 2020
Events & attendees
Scrum Artifacts
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information.
— The Scrum Guide 2020
1. Product Backlog
•What?
The Product Backlog is an ordered, emergent list of everything that goes into making of or improvising the product . The Product backlog is the single source of requirements for the entire product which may include requirements, features, enhancements, and fixes.
Please note: Scrum Guide does not recommend any template or a specific hierarchy to manage the Product Backlog. The visualization of the Product backlog may differ based on the team’s infrastructure. For example: A team using the Azure DevOps may see a hierarchy EPICS -> Features -> User Stories.
Here is a reference : Microsoft‘s process template to work in Azure Boards or Azure DevOps.
•Who?
The Product Owner is accountable for the Product Backlog, including its content, availability, and ordering. The Scrum Master and the Development Team can help the Product Owner create or update the Product Backlog.
•When?
Initial list creation happens before the first Sprint and continues to evolve.
2. Sprint Backlog
•What?
Set of Product Backlog items selected for the current Sprint, plus the Development team’s plan for delivering product increments to achieve the Sprint goal.
•Who?
The Development Team owns the Sprint Backlog, collaborate with the Product Owner to negotiate on scope changes and focus on the Sprint Goal.
•When and How?
the Sprint Backlog is updated throughout the Sprint as more is learned about the work needed to achieve the Sprint Goal. Development Team creates the Sprint Backlog with the guidance of the PO.
3. Increment
•What?
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
— The Scrum Guide 2020
An Increment is also referred as “Potentially Shippable Product”. In every increment, the team produces a value that includes the current and all previous sprints outcome. However, the outcome should be in useable condition and meet the team’s definition of done.
•Who?
Even though the Developers are the people who are committed to creating any aspect of a usable Increment each Sprint, the entire Scrum Team (the Developers, the Product Owner, and the Scrum Master) is accountable for creating a valuable, useful increment in every Sprint.
•When and How?
The entire Scrum Team works within the timebox of the Sprint, focusing on the Sprint Goal to produce a useable outcome, which is presented in the Sprint Review. The Product Owner may decide to release the increment or not. However, if the increment is not meeting the team’s Definition of Done, it cannot be released not considered complete.
Commitment
Product Backlog -> Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
Sprint Backlog -> Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.
Increment -> Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
END NOTE
Everything in the Scrum Guide may look overwhelming and impractical to practice in the real world. However, we need to watch closely and focus on every aspect that is influencing teamwork. For example, question the team on what would happen if there was no Scrum or what would happen if a Scrum Event was not there and how would the team propose to fix the problem. This will provide better insights into the team’s problem-solving skills, collaboration, and self-organization.
After reading and exploring several articles, I found that the Scrum framework and Rugby have an old connection. Many authors use this metaphor to help illustrate the concept better. In his article, Scrum’s Connection to Rugby, Paddy Corry shares interesting facts about the Scrum framework’s connection with the Rugby game.
References:
The brief history of the Scrum
The Scrum Development Process
Key Insights from the 2020 State of Agile Report
Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage — The Scrum Guide 2020
