If you find this site useful, you should try my 55-page eBook here

User Stories Should Be *Small*

by Kelly Waters

Email This Post Print This Post Save As PDF
amazing tiny art of Willard Wigan - figures in the eye of a needleUser Stories should be small.

This is what the *S* stands for in the the 'Invest' acronym; a way to remember and assess what makes a good User Story.

Not too small. But certainly not too big. So what is the right size for a good User Story?

First of all, let's get one thing straight. This statement is slightly misleading. More accurately, it should read: "User Stories Should Be Small, by the time you plan to include them in a Sprint".

Because until you come to Sprint Planning - until you're ready to include the feature in the next iteration - User Stories can be big. In fact, they can be huge. Humongous even! It's completely reasonable for User Stories that are further down the Product Backlog to be rather large and fuzzy.

As long as they are broken down before it's time to work on them, that's fine. They are still effective placeholders. So it's okay to have a User Story further down the backlog like: "As a user, I want a new system, because the old one no longer meets my needs".

These big User Stories are known as Epics.

Anyway, back to the point in hand. What's a good size for User Stories when they are ready to be developed?

Let's take my recent Example of a User Story. This could have been: "As a user, I want to register, log in and manage my details online". But I think that's too big to be a good User Story. Perhaps it started life like that, as an epic, further down the backlog. That would be fine. But at the time of Sprint Planning, a story like this should be broken down.

So let's say it's broken down into 3 stories: register, login, and manage details. The login story could potentially be broken down further, into another 3 stories, for example: login, forgotten password, remember me. In my opinion that's a nice size. The stories are very focused. Small. But still each story is still functional and fulfils its own purpose. And they're still fairly Independent.

Now let's say the login story is broken down even further. For example: "As a user, I want to enter my user id", "As a user, I want to enter my password", "As a user I want to push the login button", "As a user, I want a clear error message when my login fails", etc. Then I'd say it's gone too far. These stories are too detailed. At this level, even a small project would end up with hundreds of stories, and be very hard to manage.

In the end, there's really no right or wrong here - you need to do what feels right for you and your team. Nevertheless, I hope my comments offer some useful guidance, even if it's just as a starting point for your team to debate...

Kelly.

  • Digg
  • del.icio.us
  • StumbleUpon
  • Yahoo! Buzz
  • Technorati
  • Facebook
  • TwitThis
  • MySpace
  • LinkedIn
  • Live
  • Google
  • Reddit
  • Sphinn
  • Propeller
  • Slashdot
  • Netvibes

0 comments:

    10 Key Principles of Agile Development

    How To Implement Scrum in 10 Easy Steps

    User Stories - Agile Requirements

    Agile Project Management

    10 Key Principles of Agile

    How To Implement Scrum

    Most Read

    Agile Leadership

    Agile Requirements - User Stories

    Agile Estimating

    Agile Testing

    Agile Project Management

    Lean Software Development

    Agile Teams