How to Estimate User Stories

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

Scenario

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.

EstimatingStories_QuestionMark

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
    story
  • 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

EstimatingStories_StoryPoints

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

EstimatingStories_Team

Process

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

EstimatingStories_Calendar

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

References

Mike Cohn

Advertisements

The 4 Reasons Why User Stories are Better than Requirements Specifications

In this post I’m going to show you why User Stories are a better solution than Requirements Specifications to effectively understand user needs and build successful products.

Introduction

Software requirements is a communication problem.

How do you decide what a software system is supposed to do?
How do you communicate that decision between the various people affected?

communication_problem

Experience has taught us that Requirements Specifications do not work anymore in today’s  world and that User Stories are a much better solution.

I’m going to explain you why in this post…

What are Requirements Specifications?

A typical Requirements Specifications fragment is the following:

IEEEFormat

There is a tremendous appeal to the idea that we can think about a system and then write all the requirements upfront.

Requirements Specifications written like that have sent many projects astray because they focus attention on a checklist of requirements rather than user goals.

What Is a User Story?

A user story describes functionality that will be valuable to either a user (who uses the system) or customer (who pays for the system).

user_story

The format of a User Story is the following

As a <Role> I want <Function> so that <Benefit>

as in the example below

As an executive, I want to generate a report so that I can understand which departments need to improve their productivity

Our goal with user stories is to write down a short place holding sentence that will remind developers and customers to hold future conversations.

Why User Stories are better?

1. Comprehension

A way that extensive upfront Requirements Specifications can kill a project is through the inaccuracies of written language.

The shift toward verbal communication of User Stories provides rapid feedback cycles, which leads to greater understanding.

2. Planning

A difference between User Stories and Requirements Specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written down.

With stories, an estimate is associated with each one right up front so that they may be conveniently used for release planning.

3. Resiliency

Change always happens in projects…

  • Users and customers do not generally know exactly what they want
  • Many of the details needed to develop the software become clear only as the system is being developed
  • Product and project changes occur
  • People make mistakes

User Stories embrace change because

  • Do not need to be all written before developers can begin coding the first
  • Encourage deferring details because we can write them at whatever level of detail is appropriate in a given moment.

4. Prioritization

It’s hard to prioritize and work with thousands of sentences all starting with “The system shall…”.
That difficulty usually results in having the user considering 95% of the requirements high priority!

On the opposite, User Stories can be easily ordered by priority.

References

Mike Cohn