User Story Estimation

The estimation can be done either by a single developer, usually the Team Lead, or by the whole development squad.

Estimation Process

To get those story points estimates, the process goes like this:

1. The Product Manager discusses the feature at length with the client,
2. The Product Manager writes the necessary product documentation and user stories,
3. The Team Lead estimates those user stories.

At any given time, open communication must be maintained between the Product Manager and Team Lead.

Scale

The team uses the Fibonacci scale 0, 1, 2, 3, 5, and 8 to estimate feature stories.

When assigning points to a user story, the team follows the multi-faceted guideline hereafter:

• 0 points: no complexity, no unknowns. The effort required for implementing changes and code review is usually less than an hour, e.g., a change of text or image.
• 1 point: no complexity, no unknowns. The effort required is usually between a couple of hours and one day.
• 2 points: no complexity (as in “it’s something I have done before”), but it takes more time to implement than a one-point story. So the effort required is usually around 1-2 days.
• 3 points: medium complexity due to having some unknowns and needs for research. So developers probably know how to do 50% of it only. The effort required is usually between 2-3 days.
• 5 points: high complexity due to having lots of unknowns because either it requires lots of research or because developers have never done it before. The effort required is usually between 3-5 days.
• 8 points: indicative that the story is too complex or large, thus needing to be reworked and broken down into smaller stories.

Best Practices

To avoid common pitfalls, the following guidelines must be followed:

• DO factor in the whole squad’s abilities to estimate stories.
• Do NOT estimate solely based on your individual ability.

👉 While the Team Lead is responsible for estimating all stories in the backlog, they will not be the ones delivering all of them. In addition, each squad has engineering team members with different experience levels and skill sets. The Team Lead must account for these differences when estimating stories.

Usually, there are two scenarios:

• When it is possible to plan which team member will work on specific stories, the Team Lead should estimate based on that team member’s experience and skill sets.
• When it is not yet possible to plan which team member will work on specific stories, for instance, when estimating for stories that will be tackled far in the future, the Team Lead should estimate based on the squad’s average experience and skill sets.

No squad is identical. When rotating between projects, what worked in a previous squad might not work in the next. The Team Lead must ensure they provide estimates that reflect their current squad’s abilities.

• DO check the story points when being assigned stories and raise estimation concerns when necessary.
• Do NOT blindly accept a story without checking the story points.

👉 Team Leads do their best to provide estimations that support the planning and delivery of sprints. However, the developer working on the feature is responsible for raising any issues in the estimation. Whether due to their individual experience level, skill set, or the complexity of the task, developers must communicate with the Team Lead so that the point estimation can be adjusted or the story can be reassigned. The worst scenario is when a developer commits to a point estimation that does not reflect the actual effort.