User Story Estimation

Hero image for User Story Estimation

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

Once a feature has all the required meta-data (title, description, acceptance criteria), it needs to be estimated by the development squad.

The estimation can be done either by a single developer or by the whole development squad. We usually do not follow any formal methodology such as Planning Poker but favor open communication. We also accept and actually embrace that estimation can be biased based on who will estimate. As long as the individual or squad who made the estimation is also the one who will execute the work, the estimation will likely be correct and will represent the actual velocity of the individual and the development team over time.

Why Estimations?

Initial Feasibility Assessment

The very first place where user story estimations are being used is for initial feasibility assessments.

Typically, this means telling a client “looks like we could build this feature by the time you’d want it, would you like us to get to work on a plan?” or “given the size of the feature, we currently don’t have the capacity to deliver it by the time you’d want it.”

It’s the very first step after a client asks for a new feature or a change. Before kicking off any planning we need to give the client an idea of the feasibility and, if it doesn’t appear to be feasible, figure out some options that can be shared with the client.

Backlog & Sprint Planning

Once the feature and its story points estimation have been reviewed with the client and approved, then it is time for planning.

Working around the estimations, the Product Manager can plan the feature/change for an upcoming sprint following the priorities that were agreed with the client. Knowing the estimation for a set of user stories can give a fairly high level of confidence to the Product Manager when they plan sprints several weeks or months in advance.

Performance Monitoring

Following the planning phase, Product Managers need to ensure that the development goes smoothly and at the right pace.

Product Managers will always know their team velocity. They will use this to assess the development pace at any given point (especially after the end of a sprint).

It is the Product Manager’s responsibility to ensure that the development team keeps up a high output. If the team velocity goes down unexpectedly, while the Product Manager isn’t necessarily expected to fix the problem, they must ensure that the problem does get solved.

Estimation Process

The estimation process is very straightforward at Nimble.

We don’t use Planning Poker and we don’t conduct backlog refinement sessions. It has been proven that estimates are always inaccurate. Getting a whole team in a room for an hour or more only leads to expensive inaccurate estimates.

If you’re curious, you can check out the #noestimates movement.

We aren’t #noestimate radicals. We do estimate user stories, but we prefer doing it fast and be mindful or our and our clients’ time.

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 user stories,
  3. The Lead Developer, with the support of the development team, estimates those user stories.

Regarding the estimations scale, we use the Fibonacci scale.


We use the Fibonacci-based scale 0, 1, 2, 3, 5 and 8 to estimate feature stories.


When assigning points to a user story, we follow the multi-faceted guideline hereafter:

  • 0 point: no complexity, no unknowns. The effort required is usually less than an hour, e.g. 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 needs to be re-worked and broken down into smaller stories.