We have all been there: a backlog refinement session in which the business analyst explains a user story to the team, each developer proposes an estimate for the story (planning poker) and the numbers look quite different. What happens from here depends a lot on the team dynamics, working approach and your facilitation style.

In this article, we will see some easy steps we can follow to move forward with the estimation of the user story and not get locked in endless conversations. Additionally, we will see how to use estimates so they become assets for the team and not liabilities.

Planning Poker

Back to the situation. Our team has 4 developers and we estimate the stories using story points on the Fibonacci scale. For a given story, they estimate 2, 1, 3, 5. This is what I normally do:

1. Ask the colleague who estimated the lowest to explain the reasoning behind it.

    

2. Do the same for the colleague who estimated the highest.

    

3. Let the conversation flow about what it really takes to implement the story, while ensuring that everyone’s opinion is heard.

    

4. Try to keep the conversation short. My golden rule: this conversation ideally should not last longer than 2 to 4 minutes.

    

5. Based on the arguments provided by the team, I would propose to go with an estimate (tending more to the conservative side). For the sake of time, I generally try to avoid playing many rounds of planning poker for the same story.

    

6. If in 4 minutes we feel we are not ready to estimate the story, then it needs more refinement. If possible, we leave the estimation for the next session.

    

As you can see from the steps above, I consciously try to avoid having very long conversations about a story’s estimate or diving into the very technical details of the story.

In my opinion, estimates are useful but the actual number you assign to a story does not matter. Estimates are simply a vehicle to support planning, get the work done and drive continuous improvement for the team.

Unfortunately, in some teams estimates are not used as a mean, but instead they are used almost as a contract or as a goal per se. You might hear sentences like:

• “We need to reduce these estimates, so we can add more stories to the sprint.”

• “We estimated that this epic would be done at the end of the sprint, why are we going so slow?”

(Mis)using estimates this way leads to teams’ frustration and can cause teams to overestimate to feel safe. Estimates can be used in a much more constructive way.

Estimates for the win

These are some ways in which we can use estimates to improve teams’ performance:

• As an indicator of a team’s alignment and maturity: A good indicator that a product team is maturing and getting more aligned is the fact that they estimate similar figures. This is a result of knowing the product better, having a greater understanding of the team’s expertise and limitations, and becoming more familiar with the story writing style of the Business Analyst and Product Owner.

  
  
  

• As an input to improve story writing: There are many frameworks that help product people when writing user stories (INVEST, 3 C’s, ... ), but at the end the most useful input will come from your team. You need to write user stories that work for them. Therefore, estimates and the process to get to them is a great opportunity to improve your story writing skills. As Business Analysts, every time a colleague challenges a user story during refinement or estimation, we should open our ears and take notes.
  
  

   

• As a warning of big or complex stories: If most of the proposed estimates are too high, this might indicate that we need to further split the story to make it smaller or simpler. It is important that each product team defines the highest estimation allowed for a story.

  
  
  

• As a warning of uncertainty: If estimates are very different, this might indicate that the story still has too much uncertainty to be implementable. We should continue refining it to reduce some of the uncertainty.
  
  

   

• As an input to identify trends: This does not need to happen for all stories, nor for every sprint. Having occasionally a meeting with the team to analyze previous estimates for implemented stories helps us identify trends to improve the estimation process. A trend might indicate, for example, that the stories are missing the identification of dependencies.

   

  This meeting works as follows: each developer or pair chooses one or two stories they have implemented recently. They assess if the estimates were accurate and discuss them with the team. This assessment and the team conversation should be objective and non-judgemental, focusing on facts. To ensure this, many teams use an estimation cheatsheet as a support tool.
  
  

As a business analyst, many times I have been a bit disappointed after a backlog refinement session because we did not manage to estimate as many stories as planned. These “failed” sessions are the most useful for the team, because they provide us with a lot of information to improve the stories, to assess the team’s maturity and alignment and to already anticipate upcoming risks. Estimates do not matter much, but they are useful to improve and we should ensure that estimates are not used to hold the team back, but to push us forward.