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:
Business logic
Database/backend changes
Screen design
Testing
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:
Tiny = 1
Small/medium = 2,3
Large = 5 , 8
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.
Comments