You start the Sprint confidently but the burn down chart starts going up. Things are a lot harder than expected! Your velocity is lower than you expected. What to do?
Dropping scope
As I said in How to Correct Overcommitment during a Sprint the simple answer, when it looks like things are harder than expected, is to drop scope. You can drop entire user stories or parts of user stories (e.g. tasks).
Dropping scope will fix the problem within a Sprint, enable you to burn down to nothing by the end of the Sprint. However dropping scope might not actually fix the problem for the project.
Systemic under-estimation
Whether you leave it at “drop scope from the Sprint” depends on whether you have a systemic problem or not. You know you have a systemic problem if you can see a pattern in which tickets get harder.
If only a few occasional tickets blow up then your problem is not systemic. Estimating is a lot about averages so I expect some estimates to be low and some to be high. I’m not phased if the estimates/work some tickets go up because overall it’ll be about right. If you only have an occasional problem then “drop scope from the Sprint” is probably all you need to do. It’ll balance out over the next couple of Sprints.
There are a couple of typical patterns reflecting a systemic problem:
- All tickets get harder
- Certain types of tickets get harder
If all your tickets are getting harder than the estimates, in every sprint, then you have a systemic problem. The effect is that you are systematically overcommitting.
More subtle, but still a systemic problem, is when only certain types of tickets get harder. But those types of tickets always get harder. For example, you might have a consistent problem with tickets that
- relate to a particular sub-system, e.g. “you don’t want to touch the pricing system. It is a beast”
- interfaces with 3rd party components, e.g. “now that we’ve outsourced the pricing system we’ve noticed that all pricing changes are a bit more challenging”
- large cards that get larger, e.g. “We weren’t sure about that pricing system. A few things were a bit vague so we gave it a large estimate. But it turned out to be huge. Actually we noticed the same thing on Optimisation system – large turned into huge – and …”
Systemic problem – What to do
If you have a systemic problem there are a few things you need to do to turn it around:
- Recalibrate your estimates so you go into a Sprint with a better idea of how big things are
- Revisit your velocity and check that it reflects your actual progress
- Revisit your release plan to ensure it reflects your velocity, which probably means spreading your user stories / epics over a longer period
- Chop the release plan when the money runs out; effectively this means remove scope from the backlog to acknowledge you’re going slower than expected
- Tell people what you noticed and what you did as a result
This is not magic. A programme manager, project manager, product manager or product owner only has so many levers they can pull to affect the outcome. This is the traditional time, money, scope and quality trade off. Hard decisions have to be made – what is going to get dropped.
Regardless of the decision made, you’ll have to communicate the result so the stakeholders don’t get a nasty surprise at the end. Better yet, involve them in the decision making so they buy into the outcome.
What if you’re in continuous flow?
The above is written from the perspective of a team using Sprints. But what about teams, like mine, that use Kanban, with continuous flow rather than Sprints. You aren’t trying to burn down to zero in the Sprint, because there are no Sprints. But you might notice that some items, perhaps all items, seem harder than you expected before the developers picked up the card.
In Kanban big cards make your delivery lumpy and unexpectedly big cards hit your throughput. Throughput will be lower than you expected. You can of course just suck it up and accept lumpy delivery and lower throughput. But if you don’t want to then the corrective action is basically the same as with Sprints. Reduce the scope of the big cards, by stripping out bits (mini-features or tasks), and check if you have a systemic problem.
If your problem is systemic then, again, recalibrate your estimates, check your throughput, revisit your release plan and ensure it reflects both throughput and money, and tell people what you’ve done about the problem.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.