Estimation Techniques in Agile

User Story Estimation using Planning Poker method

There is no official rule in the Scrum guide as to how you should estimate. Agile or Scrum is not about precise estimation, but it is about collaboration and understanding between Product Owners and team and also within team. Target of all these estimation process is to have better understanding of requirements, uncovering hidden details during product refinement or sprit planning process, better scoping, better team alignment, better understanding of the Epic, feature or stories that team is going to develop, better predictability, helping team find it’s own velocity, better iteration planning, increasing committed vs delivery ratio of the team commitments and more.

In Agile (e.g. Scrum), the user stories are estimated in terms of story points, on the scale of relative complexity. The story points are used to calculate how many user story a team can take up in an iteration or how much work could be accomplished by the team in an iteration or release.

A balance is often needed though on how much time you spend estimating upfront without going into analysis paralysis.

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

In the context of the confidence of the team to deliver certain functionality, the team should consider three dimensions for better estimation:

• complexity,
• duration, and
• uncertainty

The process of complexity based estimation is also called “Sizing“.

Two major Story estimation techniques are used in Agile development:

1. The Planning Poker, and
2. The T-Shirt Sizing method

Planning Poker method

In Agile, user stories are usually estimated or we can say sizing is done using Planning Poker method. Story sizing activity is usually carried out either during Backlog Refinement or Iteration Planning meetings.

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.

There are certain rules that should be followed when following Planning Poker method:-

꙰ All scrum team members should participate in this sizing activity.

꙰ Product owners must also attend these meetings as he/she is the person who owns the product backlog items and is primarily responsible for elaborating the user stories to the team and clarifying any doubts.

꙰ Architects, Project Managers, Functional Experts, Users or other stakeholders may be invited for providing clarification, but should not interfere or influence scrum team in their sizing process.

꙰ 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.

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 process:

1. The scrum master allows the team to read the story, and, if necessary, the product owner/functional expert 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 using planning poker method, with a “one-two-three-go!.”
4. 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.
5. 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.
6. 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.
7. The scrum master assigns the effort points to the story, a.k.a “the plan estimate.”
8. Repeat until there are no more stories or the allocated time for the meeting is exhausted.

Since story points are a measure of confidence, it is impossible to make a scientific formula for their computation.

Also story points cannot 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:

* 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 on the next page →