In Why do Features Take So Long to Ship? I analysed my favourite complaint that I hear from CEOs, CTOs, and VPs of Product and Engineering: their pipeline that delivers business value to the customer works much too slowly.
I listed 3 common indicators that you'll see if your organisation is taking too long to deliver:
- Bumped Stories — stories that got bumped to the next sprint¹, sometimes repeatedly.
- Stowaways — stories that somehow sneaked into the sprint after it started.
- Overweight Baggage — stories that take far longer than the original estimates, and are not finished in time.
Actionable Causes
There are at least 17 actionable causes of the above symptoms. The following two are extremely common systemic issues, and have reasonably straightforward fixes.
- Overbooking — Too many stories are scheduled for the sprint. This can be because:
- Engineering throughput is uncalculated, or does not reflect reality.
- QA capacity does not match planned engineering throughput, violating the Theory of Constraints.
- Too much negotiation and pressure on engineering regarding story size estimates.
- "To make sure the engineers always have plenty of work to do."
- Stowaways — High priority support incidents and/or other "urgent" work enters the sprint late and displaces scheduled tasks, because sprint planning did not allow for an average quantity of incidents.
Solution
The solution to Overbooking and Stowaways is to plan your sprints more effectively, using the 3-step process outlined below.
It sounds so simple, that I am almost ashamed that I didn't always work this way from the start. However, as I became familiar with more companies, I came to discover the reason: some organisations find it difficult to look at themselves through the mirror of reality.
It sounds so simple, that I am almost ashamed that I didn't always work this way from the start. However, as I became familiar with more companies, I came to discover the reason: some organisations find it difficult to look at themselves through the mirror of reality.
1. Estimate Stories Systematically
In order to plan effectively, you need to have an idea of how much work there is to do. Each story needs to be estimated before you can plan implement it. Whatever estimation method you adopt should be standardised, simple to follow, and produce a consistent result that is difficult to argue with.
Feel free to use my method of estimating effort for the sole purpose of sprint planning.
Feel free to use my method of estimating effort for the sole purpose of sprint planning.
2. Know Your Sprint Capacity
How much effort you can practically expend per sprint? In order to plan effectively, you must know how big your bucket is before you fill it.
A good way to start is to examine what was delivered in the past few sprints. Using your choice of units, total up the original estimates for the stories that were actually delivered. The amount of work actually done is not relevant for our current purpose and neither are stories that were not delivered.
💡 You will now have a realistic measure of your sprint throughput, in terms of originally estimated effort.
🤦♂️ The first time I did this exercise, I was absolutely appalled. However, you need to recognise reality in order to start improving.
A good way to start is to examine what was delivered in the past few sprints. Using your choice of units, total up the original estimates for the stories that were actually delivered. The amount of work actually done is not relevant for our current purpose and neither are stories that were not delivered.
💡 You will now have a realistic measure of your sprint throughput, in terms of originally estimated effort.
🤦♂️ The first time I did this exercise, I was absolutely appalled. However, you need to recognise reality in order to start improving.
3. Reserve Capacity for Stowaways
Let's assume that Stowaways are a fact of life, for now. They are not necessarily; I will talk about ways to reduce these in a future article — you can subscribe at the bottom of this page.
In the same way that you determined your sprint capacity, determine the average estimated capacity that you ended up spending on the various types of Stowaways. Subtract this figure from your previously calculated sprint throughput.
💡 The value you now have is your plannable sprint capacity. This is the total effort you can effectively schedule and expect to deliver, per sprint.
🤦♂️ The first time I did this exercise, I was appalled — yes, again.
In the same way that you determined your sprint capacity, determine the average estimated capacity that you ended up spending on the various types of Stowaways. Subtract this figure from your previously calculated sprint throughput.
💡 The value you now have is your plannable sprint capacity. This is the total effort you can effectively schedule and expect to deliver, per sprint.
🤦♂️ The first time I did this exercise, I was appalled — yes, again.
4. Bonus Step: Effort Budgets
Divide your plannable sprint capacity into effort budgets that you allocate for different categories of business value. For organisational reasons, this one is not trivial to implement. See this article for details: Escape the Feature Factory trap to unleash exponential value!
Wrap-up & Clean-up
Knowing your capacity and planning effectively won't magically speed things up. However, by highlighting what your realistic development capacity is, your focus will naturally increase. This will force you to prioritise, and to cut work that is less impactful. One of the keys to productivity is to decide what you don't do. Your pipeline will be less likely to be filled with junk that has dubious business value.
I still have a few crumbs to clean up that I didn't address above:
- QA capacity does not match planned engineering throughput, violating the Theory of Constraints.
If QA is a bottleneck, you'll need to figure out why. You could apply the above arithmetic methods to figure out whether it's a throughput issue or a quality issue. - Too much negotiation and pressure on engineering regarding story size estimates.
I have seen it happen often, and yes, even tried to do it myself in the distant past. But it's incredibly stupid. Don't pressure engineers to reduce their story points estimates! Having an estimation method that is standardised, simple to follow, and produces a consistent result that is difficult to argue with (see above) can help you resist such pressure, and give you decent estimates as well. - "To make sure the engineers always have plenty of work to do."
Regardless of the folly of this attitude, if you plan your sprints realistically, your engineers will always be busy doing things that you have decided are of high value.
Spot Opening Up!
🤙 I have one spot opening up to help you make this transformation. Contact me via my bio below.
Thank you for reading this far! I will appreciate your comments, questions, suggestions, clarifications and especially corrections via this LinkedIn post.
__________
¹ I use the word "sprint" but the intention is only to refer to whatever your basic planning unit is.