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:
- The Product Manager discusses the feature at length with the client,
- The Product Manager writes the necessary product documentation and user stories,
- The Team Lead estimates those user stories.
- Open communication must be maintained between the Product Manager and Team Lead at any given time.
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 |
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 |
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 |
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.