User Story Estimation

Hero image for 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.
  4. Open communication must be maintained between the Product Manager and Team Lead at any given time.

As a generally accepted agile pattern, bug and chore issues are NOT assigned any points as these issues cannot be properly estimated.

Estimation Guidance

Scale

The team uses the Fibonacci sequence 1, 2, 3, and 5 to estimate user/feature stories.

Effort Assessment

Points Complexity Solution Mental model
1 Low Known; little to no unknowns A small feature that is well understood. Several of these stories can be accomplished in a day of work
2 Low Known; little to no unknowns A feature that is well understood – as in “it’s something I have done before” – that usually requires one or two coding sessions at most
3 Medium Generally known; few unknowns A feature that is only partly understood – as in “I have done something similar before before but not exactly the same” – so requires at least one research session to find a solution and several coding sessions
5 High Mostly unknown; Numerous unknowns A feature that is NOT understood – as in “it’s something I have NEVER done before” – so requires several sessions of research and coding sessions

A feature that is too complex, or that requires too much effort to fit into 5 story points must be broken down.

Impact Factors

The following factors, testing and codebase maturity, come in addition to the story’s complexity and must be factored in to determine the total story points.

Testing

Impact Testing Effort Description
None Normal Non additional testing effort beyond standard practice
+ 1 scale step Medium Additional testing effort beyond standard practice
+ 2 scale step High Testing effort is beyond standard practice and is equal or greater than the effort of the implementation

The impact of implementing testing can be significant in story estimation when the codebase is not testable. Such cases occur more commonly in brownfield development projects. However, such impact can also be significant in greenfield development projects for features that require deviating from the baseline testing strategy.

Codebase Maturity

Implementing the same story in a greenfield development project can require different levels of effort depending on how mature the codebase is.

Impact Codebase Maturity Description
+ 2 scale step New Little to no code exists; the implementation requires setting up the code foundation
None Mature Implementation can be achieved mainly through reusing or extending existing code

An additional scale means to bump to the next Fibonacci number by the number of steps. For example, if the story is estimated as 1, and the impact is + 1 scale step, then the final estimation is 2, and if the impact is + 2 scale step, then the final estimation is 3.

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.

When providing estimations, a Team Lead might find some stories that require little to no work.

  • DO work with the PM to review the story – e.g. merging with another story, removing the story, adjusting the AC.
  • Do NOT estimate stories to 0 points.

👉 A 0-point estimate is an anti-pattern. Either there is work (and so, code review and/or QA testing), then there is effort required from the team (even if the complexity is low, it is not nil). Either there is no work, then the story has no reason to be planned into the sprint.