How to Estimate User Stories

In this post I’m going to show you the process and techniques to effectively estimate user stories.


In our project we are using an iterative process in conjunction with user stories and we need, or are asked, to provide an estimate of how long the project will take.


Ideal Estimation

The best approach for estimating user stories would be one that:

  • Allows us to change our mind whenever we have new information about a
  • Works for both big and small stories
  • Doesn’t take a lot of time
  • Provides useful information about our progress and the work remaining
  • Is tolerant of imprecision in the estimates

Story Points


An approach that satisfies each of these goals is to estimate in Story Points.

Story Points are relative estimates of the complexity, effort or duration of a story.

A nice feature of story points is that each team defines them as they see fit.
Story points can be entirely nebulous units or ideal time units like “ideal day” or”ideal week”.
Of course, as we’ll eventually need to convert estimates into time, starting with ideal time makes that conversion a little simpler than starting with an entirely nebulous unit.

What to Include

When programmers estimate a story, they should include everything they’ll need to do to complete it.

They need to factor in such things as testing their code, talking to the customer, perhaps helping the customer plan or automate acceptance tests, and so on.

Estimate as a Team

Story estimates need to be owned collectively by the team for two main reasons:

  1. Since the team doesn’t yet know who will work on a story, ownership of the story cannot be more precisely assigned than to the team collectively
  2. Estimates derived by the team, rather than a single individual, are probably more useful and accurate



To estimate user stories as a team:

  1. Implement a baseline story
  2. Compare with the baseline story and other user stories
  3. Split in tasks

From Story Points to Expected Duration


Now we need a way to convert story points into a predicted duration for the project.
How to do that?

The answer is to use team velocity.

Velocity represents the amount of work that gets done by the team in an iteration

Once we know a team’s velocity, we can use it to turn ideal days into calendar days.
For example, if we estimate our project at 100 ideal days, then with a velocity of 25 we can estimate that it will take 100 / 25 = 4 iterations to complete the project.

It is often necessary to estimate a team’s initial velocity.
To do that you can:

  • Use historical values
  • Run an initial iteration and use the velocity of that iteration
  • Take a guess


Mike Cohn


The 4 Principles of an Effective Work Breakdown Structure

In this post I’m going to show you how to create a Work Breakdown Structure as the foundation for your project planning.


A Work Breakdown Structure (WBS) is a simple, yet methodical way of organizing a project scope in a hierarchy of smaller and manageable components and is the foundation of project planning.



So, why bother creating a WBS for your project?
Hereafter a few reasons…

  • Gives clarity on the project needs in terms of deliverables and success criteria – it highlights the “what” of the project
  • Subdivides the scope into manageable components in terms of size, duration, and responsibility
  • Aids in monitoring and controlling the project



  1. 100% Rule: The WBS should define the total scope of the project and capture ALL deliverables, including project management. If not, the risk of gaps and missing components is high.
  2. Mutual Exclusivity: It is important that there is no overlap in scope definition between two elements of a WBS. This ambiguity could result in duplicated work.
  3. Deliverables, Not Actions: Deliverables are the desired ends of the project, such as a product, result, or service and can be predicted accurately. Actions, on the other hand, may be difficult to predict accurately.
  4. Reasonable Level of Detail: Don’t go into too much detail. What you’re looking for is enough detail so you can plan, manage and control the project. An effective limit of WBS granularity may be reached when it is no longer possible to define deliverables and the only details remaining are actions. The lowest level in the WBS is called a “Work Package”.



  1. List high-level deliverables
  2. Get granular
  3. Check WBS principles



In the following image you can see an ideal Work Breakdown Structure.



WBS applies also to Agile. An agile WBS is organized around end-user deliverables. Here deliverables are decomposed into Epics, User Stories and Functionalities.