Story Estimation In Agile Doesn't Have To Be Hard. Read These Tips

Story estimation is the correlative story analysis for a calculable product delivery. The ceremony estimates the right amount work for the team(Developers, testers) in a certain time period.

Why do we need Story Estimation?

Cost estimation: Estimation gives the idea of total cost needed in advance. Based on the results, the organizations re-evaluate on many decisions.

Time estimation: Similar to cost, time is one of the main resources. Story estimation not only maintains the workload balance but also gives the rough idea on the amount of time the product will take to release.

Value estimation: The estimation makes team members become aware of their work and the values added to the story. This enhances responsibility and urgency in team members.  

So, the idea is to make the product owner understand the cost; the team about time and values. There are many types of story estimation techniques - such as voting, T-shirt sizing, Rock - Paper - Scissors, but in Agile Planning Poker is popularly used.

Story Estimation Planning Poker 

Do’s before the Story Estimation

  • What is the story about? It is very important to identify the stories, which your team is going to work.
  • The team can pick the story from the product backlog or create a new story as per the need.
  • Each team member should understand the story properly. Before doing the estimation the team needs to have the open conversation and FAQs to get a clear picture. (Such as the things they have to learn before starting the work)
  • Requirements analysis - Team does the analysis and conveys Product Owner about the requirements needed.
  • It’s same with dependencies. If the story has some dependencies then the team and PO conduct conversations to fulfill the gap.
  • Acceptance criteria of the client - The team always need to pay attention on this throughout the delivery. Because after coding, testing, if the product doesn’t come up to the customer expectation, then there’s no meaning to it.
There is a saying “It’s not always about doing, It’s important in doing it right.”

Know how to Play

  • SAFe uses Planning poker cards for a normalized estimation. The card numbers the Agile teams use are - 1, 2, 3, 5, 8, 13, 20, 40, 80, 100, ∞ and ? But in real-time teams mostly use up to number 5 (1, 2, 3, 5 - known as four-point story estimation).
  • In planning poker, there’s always an assumption based on the card 1. Agile credits any half day or full day work completion with story point 1. Relating to the card 1 the teams do the sizing of other stories.
  • The product owner retrospects the work components; gives the background details; talks about the goal. The facilitator puts a white board and writes down the estimates of each team.
  • The team discusses the story implementation. Each team selects a card and hides the number by facing it downwards. They show it when the facilitator asks for their views.
  • Obviously, the differences come in each team’s decision. The teams discuss with themselves to reach a common goal point. But it is the privilege of the Product Owner, who decides whether to accept the story at that level or not.

My first Experience of Planning Poker @ our Training Session

As per the instructions, we were given the poker cards. Our facilitator showed images of animals. We were to estimate them according to three characteristics: Size, Unknown factor, Seriousness/cleverness.

It was really fun to estimate the animals. There was a time when we had size conflict between giraffe and elephant. In the case of unknown factor and cleverness, my team voted hyena the most but other team was against it. There were many conversations since everyone’s thinking was different.

Things to Remember
  • Justify your estimation throughout the ceremony and do the sizing as per the definition of Done.
  • Make sure the definition of Done for card 1 is same for everyone.
  • Have a debate between the highest and lowest estimates to explain the reasons behind their actions.
  • Sometimes the team changes the estimation one day after planning. So before committing anything do the re-estimation.
  • Remember there are no Zeros in estimation, no matter how small the work is. Sometimes information lacking causes conflict. In that case, let the story be unestimated.
  • The safe way to reach a solution is to accept the one having most votes. But exceptional cases may arrive at some point.
  • Do estimation independently without having any influence or pressure.
  • Break the largest numbered story into pieces. So that it will be easier and less stressful for the team.
  • Sometimes estimation becomes very confusing. When stories get larger they contain more risk. But don’t stop, keep doing it. Ultimately you will find the answer.

References: http://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/ 

http://www.leadingagile.com/2014/01/10-tips-better-story-estimation/


Like this post? Share it with friends