Published on 14 May 2020 in agile
I’ve seen Sprints used and abused. They’ve been so widely adopted that sometimes organisations use them as a measure of time rather than adhering to the practices that make them valuable.
Sprints are short, timeboxed planning horizons of one month of less used to create consistency. They have an objective to acheive. Work is pulled into a Sprint Backlog at Sprint Planning according to what a team thinks it can do to acheive the said objective (or better, the data says it can do). If a team has reached a good level of consistency then we can get a good idea of what they’re going to achieve in the timebox based on what they’ve pulled in. I dig Sprints. They’re an enabling constraint. Nothing wrong with them, in the right context they are great.
But, here’s the thing; if you aren’t going to respect the integrity of a sprint (and pull things in after you’ve finished Sprint Planning as an exception rather than the rule) then there is no point using them. I’m not talking about further refinement of the work and changes to stories; I’m referring to new work unrelated to the Sprint goal coming in on a regular basis. The Sprint Plan is made redundant. The goal isn’t acheived because new work supercedes what was planned. Stakeholders are disappointed because they thought the work planned at the start of the Sprint was going to be done (regardless of the new work going in). The team is demoralised. Even if you respect the integrity of a Sprint, if you’re not breaking the work down into chunks that can get “Done” during the iteration then it’s lost a big chunk of value since there’s little predictability and consistency. Using Sprints in the wrong context is worse than not using them, as you and everyone else is fooled into thinking you know what’s going to be delivered and when. Clearly interrupting a Sprint is better than working on the wrong thing; my point is that if its the rule rather than an exception, you should look for the reasons behind it and explore other practices that work better for your context.
Good news! - Sprints are great, but there are other ways of doing things. Neither better nor worse, just different.
One way of knowing when things will be delivered is by using relative size and historical data. You can get this by simply breaking work down into similarly sized chunks. (By the way, you can do this with Sprints too, so the argument against using Sprints in certain contexts has ended and now I’m explaining how we can tell what will be delivered without them!).
So why is breaking work into similarly sized chunks better than pointing estimates?
By breaking work into similarly sized chunks we force ourselves to understand it. It’s not easy and takes longer than simply saying a big piece of work is “13 points” and putting it in a Sprint only for it to take several. But with practice it becomes easier and is much more reliable than Story Pointing.
We break the work into chunks and track the time from when work started to when it’s “Done”. This allows us to calculate cycle time, which when we know the WIP (work in the system) allows us to calculate throughput. We can then use the team’s average throughput to forecast when backlog items will be complete given their current place in the queue. You may have heard of the jargon “Velocity” which is similarly based on data. Instead of using “Story points” we’re using throughput.
To summarise, you shouldn’t use Sprints if due to your context you can’t respect them; you don’t need to use them. Provided that work is broken down into similarly sized items you can use forecasting to get as good a steer as any in a complex context of what’s going to be delivered in any time period. As anyone who has worked in delivery knows, nothing is guaranteed - but this is a good method.
Whatsmore, clearly you don’t need Sprints to do good practices (again, always depending on your context) on a regular cadence… such as Stand-ups, Retrospectives, Reviews and Refinement. Instead of Sprint Planning every 2 weeks, you can have continuous planning every week which becomes part of refinement. Instead of talking in Sprints; “which Sprint is the work forecast to be done?”, we can use any other unit within reason… “which week”?, for example.
You don’t have to use Sprints!*
*But if you do, make sure to use them as intended so that you get the benefits.