In agile, we give some value or points to each user story. These values are used to determine the implementation of story in terms of Complexity, effort and technicality. The process is called as Estimation or Sizing of user story. This is done during the Sprint Planning Meeting. While doing estimation in agile, team prefers not to estimate in terms of time. Rather team uses numbers, t-shirt sizes(S, M, L, XL) or Fibonacci series (1, 2, 3, 5, 8…) to size a story.
The question arises ‘why we use such a technique to estimate in agile?’ Well, answer can be thought as, in scrum dev team comprises of coder, testers, designers as a whole not as an individual from different expertise also it would be tough to manage the estimates from individuals of different expertise. When estimation in agile is done, every consideration from different perspective like coding, testing and designing is taken into account and then team decides how much complex the story is, what kind of effort is required and how much technical knowledge would be involved. All these thought process is packed into a common set of method (numbers, t-shirt sizes(S, M, L, XL) or Fibonacci series (1, 2, 3, 5, 8…) on which consensus is taken from the team itself. The markers given to size a story is actually a relative comparison of Complexity, effort and technicalities require implementing each story.
It can be easily understood that this method is more understandable and gives freedom to team to take on the work according to its resources.
I believe that this is not the only answer but think of as one of the answers of question ‘why we use such a technique to estimate in agile?’
Estimates also help Product Owner to visualize that how much work has been done, how much is left. The Burn down and Burn up chart uses estimated story points to show the velocity of team and position of the sprint and project condition aftermath. During the estimation process we need to make sure that entire team is involved to ensure the consistency. Over times this process gets matured and team becomes more accurate in sizing the user stories.
Planning Poker: Planning Poker is a game that is played during the sprint planning meeting for the estimation. I could think the reason to play planning poker is to cut down or avoid the influence of other or most of the times we can say senior participants. Planning poker gives equal freedom to every member of the team to think of independently on their own thought process. This is achieved by showing the card from all participants at the same time.
In order to begin planning poker, a set of cards is given to each participant. The cards have numbers on them using the Fibonacci series 0, 1, 2, 3, 5, 8, 13 and 21…
After then the story is displayed or read aloud and every participant is asked to face up the card showing the level of Complexity, effort and technicalities require implementing the story.
People with highest and lowest estimates are asked to explain their justification. The process is repeated until a consensus is reached. In the end story is assigned the number of consensus.
Overtime as team develops knowledge about the domain requirement and product structure, it helps the team to reach on the consensus more frequently within less iteration or repetition for the story. Numbers tell the significance of the story in a relative manner. A story estimated as a 2 should be about one fourth as difficult as a story estimated as an 8.
Read Similar Posts