SCRUM User Stories: As a User, NOT As a Manager

The success or failure of a piece of software, or any product for that matter, is how well its users are satisfied, and how well it solves their needs. In the world of web software, adding functionality is rarely the differentiating factor that will lead to the winning product. More likely the winner is the product that solves the user’s problem in the simplest, easiest and most delightful way.

In other words, product design is all about the user: solving their needs the best way possible. Every single line of code you write should help the user solve their needs better and easier…

… which is why I am often confused when I see user stories like “As a product owner, I want…” or “As a manager, I want…” Or worse still: “As a data centre, I want…”

Who ever asked a data centre what it wants?

User stories start with “As a user…” for a reason: the process of writing a clear sentence that starts with “As a user” forces you, with each product decision you make, to consider and understand how what you are about to do allows you to solve the user’s needs in a better, more efficient way. If you can’t do that, then you have to question why you are adding this user story at all.

Avoid stories that start with anything other than “As a user”. That’s why they’re called User stories. If you can’t work out what a user gets out of the deal, it probably isn’t worth it.

Advertisements

About Will

I'm Will. I'm a product creator, Scrum and Agile advocate, web enthusiast and change instigator. I work for Nokia and I am the Product Owner of Nokia's web social location platform, maps.nokia.com
This entry was posted in Agile, Scrum, Software management and tagged . Bookmark the permalink.

2 Responses to SCRUM User Stories: As a User, NOT As a Manager

  1. Olaf Lewitz says:

    Love this. You’re very right, and…
    There are exceptions:-)
    As a User, when I register on the site, I want to have a capcha so that… No. Users don’t want capchas. Yet you might want to still add such a feature.
    In these cases, I like to write the story in a way that it gets clear that the user might not want it. That you state clearly who’s actual need is fulfilled and that this solution is a compromise.
    As you can’t build a business with only the customers interests in mind, you can’t build a software only for the users. But their perspective should go first:-)
    Thanks for your inspiring post!
    Olaf

    • Will says:

      It’s a good point that sometimes you have to include features and user flows that users might not want or like. The Captcha example is a good one: no user would ever want that. One could argue that every single thing you do to a product should have a positive impact on the user, however indirect it may be… whatever you do you do in the interest of the business, which allows it to exist to continue to provide the product to the user… but I agree, it’s a bit of a stretch. Still, it is extremely important to consider, for every thing you build and every line of code you write, how it will impact the user. When you get into the habit of writing user stories that have someone else’s interests in mind (other than the user), it’s easy to forget the user completely. And at the end of the day, you first have to know the rules, before you know when you can make exceptions. 🙂
      Will

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s