User Story Estimation Techniques in Agile
In Agile (e.g. Scrum), the user stories are estimated in story points, on the scale of relative complexity. The story points are used to calculate how many user story a team can take in an iteration. The process of complexity based estimation is also called “Sizing“.
There are four aspects to every User Story:
- The Description: the who, what, and why
- The Confirmation: the acceptance criteria
- The Conversation: the story review or grooming
- The Estimation: the story point estimation or sizing
Story points are primarily a measure of the confidence of a team to deliver certain functionality in an iteration. Higher the confidence of the team, lower will be the estimate.
In the context of the confidence of the team to deliver certain functionality, the team should consider three dimensions for better estimation:
- duration, and
Two major Story estimation techniques are used in Agile development:
- The Planning Poker, and
- The T-Shirt Sizing method
Planning Poker method
In Agile, user stories are usually estimated/sizing is done following Planning Poker method. Usually sizing activity is carried out during Backlog Grooming or Iteration Planning meeting. All scrum team members should participate in this sizing activity. Product owners must also attend these meetings. Architects, Project Managers, Functional Experts, Users or other stakeholders may be invited for providing clarification, but should not interfere or influence scrum team is following Planning Poker method for sizing user stories.
– Agile “planning poker” cards can be used for the activity, or simple numbers are written on paper prior to the meeting and distributed to scrum team members.
– Sizing/estimation using Planning Poker is an abstract method which takes the focus off of the actual time in hours or days and instead puts the focus on describing the relative expense and complexity of a task as compared to other tasks.
Scrum team use Fibonacci like numbers to estimate effort: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
- Number estimates are based on relative sizing that the team feels is appropriate.
- Zero “0” means no effort required to complete this story (functionality might get created due to completion of some other user story); 1 means the story is trivial; 5 means it’s average; 20 means it’s extremely difficult or much remains unknown.
- If the team provides an estimate of 3 or 5 or 8 then those user stories are perfect for this team.
- 13 means the team is asking nicely for you to break the story down into smaller pieces if possible.
- 20 or 40 means the team is telling you that story is too big and it must be broken down into multiple smaller stories.
- The scrum master allows the team to read the story, and, if necessary, the product owner/functional expert explains the story.
- 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.
- For user stories or derived technical stories, the scrum master asks the developers to vote using planning poker method, with a “one-two-three-go!.”
- The scrum master then challenges the highest and lowest votes to explain their position and rationale behind their selection, i.e. why they believe it is more or less difficult than their peers expect.
- The scrum master repeats the votes until the numbers converge and the team as whole can agree to a number or some time to nearest numbers.
- If the team has not agreed to a single number then the scrum master decides the best number based on number of votes or sometime giving more weightage to the vote of team members who are most likely be working on that particular user story.
- The scrum master assigns the effort points to the story, a.k.a “the plan estimate.”
- Repeat until there are no more stories or the allocated time for the meeting is exhausted.
Different size of story by different team members represent difference of opinion on complexity of user story. Team should have discussion on that, so that every one is on same page.
Since story points are a measure of confidence, it is impossible to make a scientific formula for their computation.
Also story points can not be directly mapped to efforts in number of hours but based on historical data from last couple of iterations of a particular team, some patterns can be derived for mapping certain story points with number of hours, but that mapping can vary from team to team based of their capability, experience, motivation or technology used.It is recommended NOT to compute an average or derive a pattern until the team has completed a large number of user stories.
Please note that:
* Fibonacci number represents a range, its not a discrete value.
* The larger the number, the larger the range.
* Ranges may overlap from one number to the next.
T-Shirt Sizing method
Sometimes teams find themselves over analyzing when trying to use Story Points. Thus by removing the implied precision of a numerical scores, the team is free to think in a more abstract way.
T-Shirt Sizing method is a quick way to estimate the size of an User Story (sometime Epic as well for high level estimation purpose), as it can be achieved with a series of yes/no questions.
- We hold up story A and ask “Is story A double the size of story Z” (with story Z being our yardstick), if the answer is yes,
- we then ask the question “Is it more than double the size of story Z”, if the answer is also yes, we then
- ask “Is it four times the size of story Z”, if the answer is no, we then mark the story as a “large” and move on.
- All the team member use their initial gut feeling and not to over think it.
- If there are some wildly different estimations coming from different team members, for example one says “small” the other says “large” I ask each member to explain the reasons for their estimation until the team reaches a consensus.
Author:Mohammad Sami, Agile Transformation Coach
3,513 total views, 1 views today