Estimation is the process of finding an estimate, or approximation, which is a value that can be used for some purpose even if input data may be incomplete, uncertain, or unstable.
One of the key principles of user stories is that it should be estimable. Below are the common questions on agile estimation.
- Who estimates when and why?
- How do we estimate the user stories?
- What can be the unit of measure?
- What is velocity?
- How do we plan for the sprint/release with the help of estimates and velocity?
A common technique is to estimate in terms of relative size factoring in effort, complexity, and uncertainty. The unit for this relative estimating is story points.
- Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work
- A story point range is commonly a Fibonacci sequence as 1,2,3,5,8,13,21,34,45…
- Why story points instead of man-hours?
- It is more accurate
- Prevents the need for frequent re-estimation. Works like a size-based estimate.
- Allays fear of commitment.
- Humans are good in relative estimation compared to absolute.
- It is faster
Velocity is the number of story points you can complete in an iteration.
- It is a measure of how much Product Backlog the team can complete in a given amount of time
- It uses a feedback loop: every iteration’s velocity reflects what the team actually achieved in the previous iteration.
- Velocity tends to be unstable in the beginning of a project. Give it three or four iterations to stabilize.
- Velocity can be calculated by
- Using historical data for a team
- Running an iteration
- Making a forecast
It is an abstraction of the number of hours you would normally expect a developer to be productive during a typical day, subtracting time for meetings, breaks, etc.
- A task that requires eight hours of uninterrupted concentration can take two or three days if the programmer must deal with constant interruptions.
- The advantage of using ideal time is that we estimate in hours which we are actually thinking
- But it isn’t as accurate as story points though it can be consistent within a team
Who, Why and When to estimate?
Who participates in the estimation?
- Every team member participates in the estimation
- Estimation of every story is finalized only after the team consensus
- The team has its final word on the estimates
- Why do we estimate the product backlog items (PBIs)?
- So that the product backlog can be prioritized based on at least the relative cost.
- We can make high-level forecasts about how much will be done by when
- We can make tradeoff decisions between scope and schedule
- When should the product backlog items be estimated?
- The first set of PBIs are estimated before the first sprint begins
- Estimation and re-estimation happens during the sprint planning meeting
- As the product backlog grows, so should the estimation happen, most commonly once a week with a backlog refinement session
How to estimate user stories?
- Identify how long will the story take if you experience no interruptions, can pair with anyone else on the team, and everything goes well?
- Use the unit of measure that suits you – be it story points or ideal days or even simple t-shirt sizes.
- You can equate a story point to some ideal days value and use story points for estimating. eg: Define 1 Story Point = 1 Ideal Day
- Stories are estimated across 3 dimensions: complexity, duration, and uncertainty
- Best estimates can be obtained when you
- Keep estimates manageable.
- Estimate in relative terms.
- Bucket backlog items by story size.
Estimation using Planning Poker
The Planning Poker Process
The scrum master allows the team to read the story, and, if necessary, the author explains the story.
2.The scrum master facilitates the discussion on dependencies, and what technical stories or technical tasks need to be accomplished to support the story completion. The technical stories or tasks are noted.
3.For user stories or derived technical stories, the scrum master asks the developers to vote, with a “one-two-three-go!.”
4.The scrum master then challenges the highest and lowest votes to explain their position, i.e. why they believe it is more or less difficult than their peers expect.
5.The scrum master repeats the votes until the numbers converge and the team as whole can agree.
6.The scrum master assigns the total effort points to the story, a.k.a “the plan estimate.”
7.Repeat until there are no more stories or the allocated time for the meeting is exhausted.
Estimation of Epics
- The entire scrum team should be involved in the meeting
- Stories are estimated for complexity and uncertainty
- Team members can use the following scale to estimate the epic:
- 40, 60, 80, 160, 320
- A “40” means that some things are still unknown and the team believes that there is some complexity to it
- An “80” means that a lot is still unknown and the team believes the implementation will be complex
- A “320” means that there is much uncertainty and that the team believes the implementation will be
Agile Estimation & Velocity - Summary
Remember that there are no direct prescriptions from scrum on how to do the estimation
- The team as a whole participate in the estimation
- User stories in agile projects are relatively estimated
- Story point is a unit of measure which is widely used which calculated based on complexity, uncertainty and effort.
- Velocity is the sum of story points of the done user stories
- Velocity is used to plan for the subsequent sprints
- Ideal Days is the actual days required to complete a work with no interruptions
- Ideal Days is not equal to calendar days
- Planning poker is the most common estimation technique followed in agile projects
- Epics are estimated at high level before the projects kickoff or before a release plan.