Let's start with what is Estimation?
Estimation is a process to find the approximate value which is usable for planning purpose even if the input is
incomplete or uncertain.
Example à Planning a trip, how long it takes to reach Pune from Mumbai
Ans à Approximately 3 to 4 hrs. that is your approximate value,
Unknown traffic conditions, change in whether, car breakdown - these are your uncertain inputs
How to do estimation in agile projects
In waterfall projects. where requirement were getting freeze before the start of the project . It was easy to estimate using
Function points, Use case points methodology but then also estimates were never perfect. Then how to do estimates in agile projects where requirements are not signed off or not complete. The requirements are always evolving because agile development works on principle of responding to change over following the plan. Then how to do the estimates
Use story points --- What is story points?
Story points is a random measure used by scrum team to estimate user stories
In simple terms it a number that tells team how hard the story is. Hard could be in terms of complexity, unknowns and efforts.
Most commonly used story points range is Fibonacci sequence 1,2,3,5, 8 ,13, 21, 34,45 .Nowadays most agile teams used the modified version
of this which is 1,2,3,5,13,40 ,100.
Reason of this modified version is the original sequence talks more about mathematical accuracy whereas real projects are not like that.
Again never confuse this numbers with hours. It is relative term .Since story points have no relevance to actual hours.
This makes easy for scrum teams to think abstract about the effort required to complete the story. [Dev. + testing]
Question may come up in your mind how to use something that is abstract.
As human beings and developers :) we are actually not that good in estimating the accurate time …because development is not some linear progression from start to finish. Sometimes we write 90% code within hours and for remaining 10% we tear hair out debugging for next 2 days.
But by using the abstraction [i.e. story points] takes the focus off the actual time in hours and days and instead put the focus on describing the complexity of a user story as compared to other user story. I believe as human being we are good in doing the relative estimate.
Going back to example of estimating the hours to reach Pune from Mumbai by road -- it takes 3 to 4hrs
Now if ask to estimate the exact time in hours it will take to reach Goa from Mumbai … it is difficult to tell in precise hours and minutes format and also time consuming to derive to precise estimation .
But if I ask you compare the mumbai-pune travel estimates and tell if it takes twice / thrice/Half that travel estimates…
then it's easy to come up with estimates… Story points also work on the same concept.
How to identify which story is 3 and which story is 5 …
Trick here is to pick baseline story [remember Mumbai-Pune 4hrs this was baseline story].
Baseline story need not be complex or simple story but it should be story to which all team can relate too.
From then on sizing should be done compared to that baseline story.
Story points based estimates removes the commitment of time from developers.so that developer can focus more on problem fixing.
Who all should be part of story point estimation exercise ….
Team responsible for story completion should be part of this exercise. All the team members should actively participate in this exercise.
Use planning poker for estimation
Team responsible for story completion should participate in planning poker, the first step here is
1. Discuss the user story in detail
2. Ask individual team member to estimate the story in terms of story points [1, 2,3,5,8,13,40,100] using the planning poker cards.
3. Once team members are ready with estimates then all the members should display the cards at the same time
4. If there are wider difference in estimators then brainstorming should be done with reasoning for each estimates.
5. Continue this till team agrees to estimates.
Let’s do the estimates using planning poker card.
First we will identify baseline story -- say for example auditing story
As user I want to audit when patient preference is modified so that I can manage the preference history
Acceptance Criteria
a. Audit is logged when patient preference is modified
b. User who modifies the preference is recorded
c. Before and after values should also get logged
Team come up with estimates … Dev. says 3 and QA says 5. Agree to either 3 or 5 after having healthy discussion between all team members J
Pick another story and compare this with baseline story and come with story point required for story completion.
Tips and tricks for successful story point estimation
a. Identify the base story
b. Discuss the story in detail among the team members
c. Jot down the points you want to remember when implementing the story
i. Questions to ask themselves when sizing the story
1. Design - anything new I need to learn before we can start the story
2. Coding - how much new code do I need to write? Similar code available or not?
3. UT - any special setup [mock objects] require for UT
4. Integration points - any external dependencies
5. Expertise -does anyone of us work on similar story before
How can be user story points used?
Once team starts working on iteration and delivering the user stories .Velocity of each team is calculated which helps the
product management to come up with long term prediction about the future releases.
One thing I like to make clear here velocities across the team is never compared by management they use the data for prediction of future releases.
Team A average velocity per iteration is 30 points
Team B average velocity per iteration is 45 points
Team C average velocity per iteration is 15 points
Team D average velocity per iteration is 30 points
Addition of all points / no of teams ---> 120 / 4 = 30.
Average velocity of feature team per iteration is 30 Story points
So when product management estimates their backlog for future release which for example is 3600 story points
then they can predict that 3600/(4*30) = 30 . With four teams they can deliver the new product in 30 iterations.
then they can predict that 3600/(4*30) = 30 . With four teams they can deliver the new product in 30 iterations.
Our iterations / sprints are of 2 weeks duration. That means in a month we can complete 2 iterations
30/2 = 15 months required to deliver the new product with four teams
This is how story points are used.
