🚩Mind the red flags: is your story point planning working for you?

How can you recognize if it is not, and what can you do to improve both your long-term and short-term planning sessions.

The new year is here, and that means two things: vaccine 🙏 and fresh rounds of yearly and quarterly plannings 🤦‍♂️. We have finally figured the first one, but the planning is a tougher nut to crack. We hear questions like this every single time:

“How do you convert story points to manhours?”
“How many days is an M-sized shirt?”
“Give me a high-level estimate!”

While we have numerous estimation techniques at hand, we struggle with when to use which and how to connect them all together. And with the best of intentions, we usually end up overcomplicating the process. Story points are a great tool to solve this, but we often keep misusing them.

I have prepared a list of the red flags that I observed in my teams over the years. And a list of tips on how to improve your estimations.

🚩Red flags in short and longterm planning

Stop and inspect your longterm planning process if you:

• you never use high story point numbers in your estimations
• not all competencies (product manager included) are represented on the estimation
• different competencies provide their estimates independently
• you are estimating one story at a time but without the context of other stories
• you are discussing low-level implementation details code, database, etc.
• you do not yet know how you will link the short term estimates to your sprint planning
• you think that the time spent on one story estimate is too high

Stop and inspect your sprint planning process if you:

• most of the stories in your sprint backlog share the same story point value
• you estimate each idea only once before taking them into a sprint
• need to know the exact solution before you are willing to estimate
• “know” how many hours is one story point

Why are these red flags so common?

The word “estimation” is an umbrella for multiple different activities in different stages of the story life cycle:

• In sprint planning, we mostly deal with stories in Discovery and Delivery stages. And we want to know how much can we do in one sprint.
• In short term planning, our stakeholders want to have some rough estimate of when they can expect the stories in the roadmap live.
• In long term planning, we usually have pile stories in the Idea and Discovery stages. The product manager needs to figure out which of them to build first.

These are all different use cases with very different levels of unknowns. And yet, we “estimate” in all of them.

The story points are a great tool to bridge between these use cases. Yet, many teams trap themselves using story points like manhours just before the sprint, rendering the story points useless for other estimation use-cases.

Why is this a problem?

Because to find out what you should build and how you should plan your sprint, you do not need to think about the solution and burn the precious time of your development team.

And vice versa, if your developers are used to estimate story points only for sprint planning, which usually results in a commitment of some sort, they will not be willing to estimate anything vague. This often influences other types of estimation, where no commitment is needed, but developers naturally tend to refine and overthink solutions even in the early stages of the story lifecycle.

Also, when not using the story point estimation for the entire process, you may be tempted to let silos estimate things separately. By omitting the discussion between silos, you are not using the team Multiplier Effect to its full potential, depriving yourself of out-of-the-box ideas and quick wins.

Solution? Do not think of estimation as a single activity.

Think of your estimations as a continuous process instead of separate meetings on the timeline. And in this process, we use story points to distinguish what can go for delivery and what needs more grooming by the developer/product designer before we hand it over to our development team.

Long term planning

Let’s start with long term planning. Why can we not use the story points here and estimate even rough ideas with nothing more than a user story and a few explanation sentences by the product manager? Is there anything that holds us back?

In long term planning, we typically have a pile of stories in different stages ranging from fresh ideas to “ready for delivery.” And we usually have many more stories and ideas than we can ever deliver. And we need to figure out somehow which are the right ones to build.

We don’t need to decide here whether something can be done in a sprint or two. Is it important if the 8-story-point-story takes in the end 7 or 14 days to complete? No, it’s not, because it will not change its place in the backlog. The proportion of the effort towards all other stories remains the same.

Imagine the outputs of these estimations in the form of a value/effort matrix. Ideally, we want to identify any quick wins first and then decide what to do about Big Bets or Maybes. The exact time estimates do not concern us at this point.

Story points from the Product manager’s perspective in the value/effort.

The stories with low story point value can are quick wins. And they can go straight into the sprint. The details can be figure there. Why debate them if we can deliver them fast? Deliver them and measure them in production.

The larger stories need to be probed before moving them to delivery. The large story point value indicates the high uncertainty and that we are in the discovery phase.

As the understanding of the story by the team understanding increases (through design sprints or spikes that validate your hypothesis), the team will be able to break the larger stories into smaller ones and re-estimate them with fewer story points.

Sprint planning

Up to this point, story points from the development team’s perspective are really just a tool to distinguish between stories. The development team should have an agreement on the maximum story point value they are willing to take into the sprint.

Once we have these well-refined stories granular enough to be taken into sprints, the team should do so.

The team can then take stories into the sprint as they are or break them into even smaller tasks that they can estimate in manhours if, for some reason, they need to.

With my teams, I usually ask the question, “If we start on this right now, is it going to be done by tomorrow evening?” I found out that this two-day window is enough for most medior developers to guess correctly.

If the answer is now, the should be broken even further or your team should think about lowering their story point value limit.

How to do the actual story points estimation?

Sadly, there is no silver bullet that would work for every team, but this list of tips worked for me:

• Have a regular formal estimation event not tied to the sprint backlog
• Do it as a team and have every competency present
• Use the reference table or visually order the stories on the canvas so you can see them in the context of the backlog
• Estimate everything in the backlog, even rough ideas
• Use all the SP values available
• Review the estimation process after it and experiment with the setup

What sequence to use?

I recommend using the Fibonacci or planning cards series since it’s nonlinear better represents the nonlinear uncertainty. More on this in this article by Mike Cohn.

Key takeaways

• There are different types and precisions of estimations. Before every estimation, think about the reason why you estimate.
• Estimation is not a single point in the feature lifecycle.
• Let your team estimate together from the beginning. Otherwise, you deprived yourself of the best solutions.
• The question “If we start on this right now, is it going to be done by tomorrow evening?” is more powerful than you think.
• Use story point estimation to distinguish what can go for delivery and what needs more grooming by developer/product designer, not only to estimate effort.