Why committing to less story points will increase your velocity

Planning poker and sprint planning are tricky areas, and we can improve the team velocity a lot by only committing 80% to the team capacity. Here’s why:

Sadly, no-one estimates perfectly, and with human bias, estimations of story points will then become currency. And when teams start massaging estimations, many things will go wrong. The reasons can be plenty, from cases like “I don’t want to do this, I’ll estimate higher”, or “Let’s score this lower so it can fit into the next sprint with the other important bits”. Story points by the definition are.. estimated. And far off…

… because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know… — Donald Rumsfeld, US Secretary of Defense

Lets see an example: Let’s say, you have estimated a few stories for the sprint as ½, 3, 5, 5, 8 points, and your velocity is 22:

The summary of these points are 21.5, so this is less than the team’s velocity, and as there are no holidays, or extraordinary trainings expected, this should fit your sprint backlog nicely, right? Let’s analyse:

How the story points value is statistically expected even in an ideal estimation: ½, 3, 5, 5, 8

This example and the distribution is fictional, however based on an article from Erik Bernhardsson building from an estimation and effort dataset, gaussian curve is a good representative model for the problem.

So notice this graph: First of all, since we’re talking about estimations, they can be higher or lower in value, and likely are. Also by the nature of some stories, unknown of unknowns, you can have more and more deviation. This can be managed within some boundaries with the risk discovery Cynefin Framework. Also you can see how lower estimates should be more punctual, advocating for proper slicing, and what is also the reason for the use of fibonacci sequence in planning. While that copes for humans being terrible in guessing unknowns, it is also adding additional deviation. You can also see how the same 5 pointer stories can have different deviations. Here I’d like to pinpoint, I used standard normal distribution on calculations to help understand my point. In reality, the near-peak are more flat, and the far-peak should be more rare. Also there might be some asymmetry due to work that far often gets longer than shorter, and it is also immeasurable due to the points representing complexity.

If the mathematically expected value remains the same, across the sprint you can have a huge deviation (the aggregate of all stories will have the square sum of each estimations deviation), in other words, when committing to your exact velocity, you’ll have 50% of chance to fail the sprint, without any surprises! And if you factor in interruptions, like sickness, system downtime, urgent live issues, you’re already at terrible odds to complete your sprint backlog.

This is the reason, why sprint goal is an essential part of plannings nowadays, as it “helps setting priorities when ’the going gets tough’ ” — scrum.org definition. Scrum does need a rail for when things are getting hard. Because they often are. In fact so often, we should always aim to prevent it.

Does this estimation of 21.5 points give you confidence for a sprint? How about 80%?

Of course the estimates’ punctuality depends on the type of work, the team maturity, and many other factors. Good teams will have a narrower bell curve, while others will have a wider.

My suggestion is to commit less! If you commit to 80% of your velocity to a sprint, that means you only have 19% chance to not finish the sprint (I did the maths), meaning you can agree to a more secure workload to your PO, therefore making safer long term estimations, improving business relationships and team trust. So what happens if we finish sprint early you ask? Well, there are plenty of ways to make use of extra time, I can recommend any of these:

• Celebrate! No business wants burned out teams, and as much as we should celebrate our failures, we should celebrate our successes as well! This will give extra motivation for the future, help the team bond, and make sure the environment is healthy. Mental health is extremely important, and taking a breath before the next sprint will also help focus and dedication. Burnout is one or the factors that affect productivity as Described on The State of DevOps 2019 report.
• Help others: when committing to less workload you can support other teams or other team members without the guilt of sprint work having to be done. This is definitely not a zero-sum-game, if you help others, the business will be thankful, and others will be more likely to help you as well, when in need. Spending ‘free’ time on knowledge sharing will get everyone further.
• Invest in self: Perform your learning, training activities, or just the missed code reviews.. You can use the well-earned time to improve yourself, therefore in the long run improve the sprint velocity further.
• Pay off tech debt: I prefer the loan metaphor for tech debt, and just as on a mortgage if you have extra income, you pay off from it, so the interest rate will get lower. Same goes for tech debt. But beware, instead of fixing what you deem dirty, always tackle what will bring benefits for the team. You know the roadmap, business plans should be aligned with the team. Fix what will increase your pace. Technical Debt also affect productivity as seen on The State of DevOps 2019 report.
• Start preparing on coming stories: Some teams are behind backlog grooming, so this freed up time can be used to clean up the backlog, prepare a move on the dependencies or unknowns, so when you’re actually doing the work, or estimate, you’ll have a better understanding, and more confidence.
• Just carry on: Sometimes the business is ambitious, or the team wants to get an epic out the door. Starting to work on the next sprint is always welcome, put the story in progress, and start the work. However don’t bring it to the current sprint backlog, as it was never committed. Just be sure that the backlog is neat, so the story is likely to get into the sprint.

As you can see, all of these options will help your team to increase velocity for the long run. Keep in mind, in this method your velocity will not anymore be counted based on completed story points, as compound interest would bite hard. So how do you adjust the velocity of the team? Pretty much as usual: the 80% commitments in a 2 weeks sprint means you have a good chance to finish 2 days early. If the team is usually finishing the sprint more than a day ahead, you can slowly adjust. If your team usually doesn’t finish in time, of course you’ll need to lower your expectations. I do think it is ideal to have 1 day for the above non-sprint improvements.

So to summarise, if you don’t commit to 100% load in a sprint, the team will

• Gain consistency
• Have a positive feeling
• Won’t burn out
• Be more helpful across the business
• Be able to improve own velocity and invest in future
• Be more predictable
• Be prepared for the unexpected
• Be more successful
• Have improved productivity

If you found this useful, please consider subscribing! I plan to write on similar topics soon! Any claps are appreciated :)

#agile #scrum #planning poker #estimates #lessismore #mentalhealth #productivity

Thanks for my helpful friends for comments and suggestions on this article: Miguel, Francisco, Heorhiy.