🚩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:

🚩Red flags in short and longterm planning

Stop and inspect your longterm planning process if you:

  • 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
  • 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 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.

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.

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?

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

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.

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:

  • 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.

Prague based full-stack developer and agile practitioner. Engineering Manager at @productboard 🚀