A deeper understanding on…
The Sprint
Road to PSM III — Episode 10
“Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.”
— The Scrum Guide.
During a Sprint the team is focussed on what is most valuable now. they also strive to become a little bit better each sprint. They improve
a. the product, b. their work environment and c. themselves.
Routine
Every Sprint, the team gets together on regular, consistent intervals. Consistency reduces complexity. In repetitive (iterative) cycles Increments are created. This routine enables continuous improvement; transparency, inspection and adaptation. This should eliminate, to an extent, the need for other meetings. With Scrum, teams don’t idly sit around a table, but actively work together to do inspections and create actionable short term plans. Counter to disciplinary segregation, they are cross-functional and collaborate throughout the day when needed. This is a great counter to meeting-cultures.
Though a team strives to deliver “done”, working Increments, this is not to say these are final once delivered. A powerful mechanic of Scrum is the ability to continuously improve. In my experience I noticed several teams had a ‘deliver and forget’ habit. Once they finished work in a Sprint on a Product Backlog Item, they never returned to it. After the Sprint Review, they weren’t collecting feedback, inspecting its use, nor suggesting or attempting improvements. Often they weren’t inspecting how what they delivered was used and experienced, because they were already focussing on the next new shiny thing. At times they’d even joke about it being better that they (or the client) didn’t know. 🙈
At times I noticed teams extending Sprints to process feedback or fix defects, or finalise something that isn’t yet “done”. Have they forgotten about the incremental nature of Scrum?
Timebox
The Sprint and its events have a Timebox.
A timebox is an agreement made upfront about the duration of a certain activity. The maximum duration for a Sprint in Scrum is a calendar month. Teams are free to determine the interval, but it is advisable that these remain fairly consistent.
“Sprints have consistent durations throughout a development effort.” — The Scrum Guide.
A timebox cannot be changed once in progress. Many Scrum Teams determine the timebox of a sprint in a number of weeks (one to four) and adjust the timebox for its events accordingly (save the Daily Scrum). Scrum doesn’t prescribe this, but does say that with shorter Sprints, their timebox tends to be shorter too. It is a common practise. So with a one week Sprint, the timebox is generally two hours for a Sprint Planning, one hour for a Sprint Review and fourty-five minutes for a Sprint Retrospective.
A steady routine enables fast habituation. Excellence is an art won by training and habituation. We are generally used to a weekly rhythm. In my personal experience this makes a single week Sprint, although ambitious, feel very natural and practical to exercise. Every week is consistent with the moments of events. Not all teams will be able to deliver qualitative working increments in this timeframe, but figuring out how to do this might be one of the most valuable exercises a team can engage in. A Sprint has to be short enough so a team can adapt to changing conditions. It also has to be short enough so the work can easily be integrated. Big increments will make integration complex and increases the risk of technical debt.
The timeboxes for Sprint Events only have a maximum duration, no minimum. This means they might end sooner. Over time Scrum Teams should learn to have more effective and meaningful events. A popular argument teams make for example, is that they feel the Daily Scrum is mundane as they are already aligned. If this is truly the case, then nothing prevents them from having only a three minute Daily Scrum in order to confirm if they indeed are aligned.
Sprint Cadence
Sprints are consistent and continuous. The timebox for a Sprint may not be shortened or extended after it started. It’s a heartbeat that ought to remain consistent. I’ve witnessed all sorts of reasons or excuses for Sprints to be extended while in play, but these three being by far the most common:
- The Sprint isn’t “Done” yet. Which exposes challenges in Forecasting or setting Sprint Goals.
- Essential members are indisposed, thus it makes no sense to continue. Which might just indicate a lack of team commitment, sense of responsibility in self-organisation or cross-functionality.
- The Product Owner (or team) need more time to do pre-requisite work for the next Sprint, like processing feedback, updating the backlog, finalising designs or putting in place technical infrastructure. This might indicate the team has isn’t effectively engaging in Backlog Refinement or utilising the events.
If your Sprint Cadence is unstable, I reckon that ultimately your product will be too.
The Sprint Goal
Every Sprint has a clear purpose and thus a goal that is collectively formulated by the entire Scrum Team. This goal may not be altered during the Sprint. Also, quality goals do not decrease!
So as long as the Sprint Goal is not put at risk, the team may respond to change. Changes are valuable. A team will learn to calmly and professionally react to newly discovered complexities.
Good Sprint Goals can aid the team in creating a selection of coherent Product Backlog Items. This selection is called a Forecast. The Sprint Goal enables a degree of flexibility in what the Development Teams will choose to implement.
Sprint Goals may be ambitious (it’s a goal after-all) and promote collective collaboration. Each member should be able to contribute to the Sprint Goal. Note that the end of the Sprint isn’t a deadline for the Sprint Goal. A team commits to putting in a reasonable effort to try and achieve it within the Sprint’s timebox. It can (and perhaps should) be the case at times that a team won’t make it. A team may have performed splendidly, yet still failed to reach it. I’ve often worked with teams who at times didn’t meet their Sprint Goal. They were superb teams, who set great and challenging goals and always strived hard to try and meet them. Not meeting them was disappointing at times given the effort they put in. But the learnings from a retro were even more valuable. Consider the distinction of ‘the ability to deliver commitments’ vs ‘the commitment to strive to achieving Sprint Goals’.
Forcing teams to meet goals, even to work overtime if they are challenged, will not motivate teams to set ambitious goals, on the contrary. This said, each member should at least consider the goal it sets for itself to be achievable. Not every Sprint Goal needs to be ambitious. Remember:
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — The Agile Manifesto.
The Sprint Goals shouldn’t result in exhausted, demotivated developers; on the contrary! Development Team members should find the Sprint Goals motivating. With motivating Sprint Goals, the teams will put in the extra mile on their own account. They make their job worth it. The goal should help the team to better understand why they are putting in the effort. A great Sprint Goal could enable teams to deliver lots of value with limited effort. So when designing Sprint Goals, consider:
“Simplicity — the art of maximizing the amount of work not done — is essential.” — The Agile Manifesto.
Continuous Improvement Goals
Not commonly known to teams is that they don’t only have a Sprint Goal, but they too have improvement goals, which are formulated during the Retrospective for which an actionable plan is created in the Sprint Backlog.
“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.” — The Scrum Guide
When members of a Scrum Team indicate that they don’t really care much about either formulating or realising these goals, the team might lack creativity (or empowerment). This may be the case when Product Backlog Items in general don’t really have any coherence, or the team isn’t truly collaborating cross-functionally. In these cases it may be advisable to set goals that promote creativity and cross-functional collaboration first.
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.
In the next episodes I will deep-dive into a powerful ability of the Product Owner: the authority to cancel Sprints.
Sprints reduce the risk of cost to its timebox, but there is much more to explore on this subject. So I’ll also dedicate an episode on some of the commercial scrum conundrums.
