top of page

Story Estimation



Well, here are the guidelines on which our teams at Giant Leap Systems, estimate a particular AGILE story. In my previous blog, I have covered the topic of why we chose planning poker and Fibonacci numbers as a preferred method for estimation. To take that discussion further, here I will cover how we exactly estimate a story.


During the backlog refinement, we only concentrate on the business requirement of the story. We leave a story with its done definition from the point of view of the product owner. The story estimation is done in the sprint planning meeting.


At that stage, a story is well debated to the extent of knowing the details equivalent to a technical design specification document. We even break the story into technical/non-technical sub-tasks. The inputs are noted and complexity is understood keeping in mind the below four aspects of the story:

  1. Business logic

  2. Database/backend changes

  3. Screen design

  4. Testing

  5. Story size

Based on this, all the team members are expected to throw in a number (1,2,3,5,8,13) from the poker cards they hold.  We categorize the complexity deducing the  number as:

  1. Tiny = 1

  2. Small/medium = 2,3

  3. Large = 5 , 8

  4. X Large = 13

We see variants across categories. We go with the highest if the variants are two or less. Else, we go into the further discussion until a number is agreed upon.


We have been doing this for a year now and after each of our retrospective meetings, we ponder over the insights that we come up with as a team and keep getting better at it all the time.

1 view0 comments

Comments


bottom of page