What can you find on the product backlog? Part 1: the user story

When you know what the objective is, you can start making a list of what you need to forfill that objective. This list is called a product backlog.

So, to be able to answer the question what you can find on the product backlog, you need to know what you lack to meet your goal.

There are many ways to form a product backlog item. I like user stories. This is a good form for a great part of the product backlog. So, what is a user story? The basic is that you specify a kind of user, what he want to be able to do and if it is not self explaining: why he needs that.

To be able to specify a user story, you need to know who are your users. You can use personas or you can hold a seminar with stakeholders. The important thing is that everyone that reads the product backlog should be able to understand which kind of user you are talking about.

For us, that has resulted in an hierachy of users and user groups. We first have the basic User, who can be anyone from an end user to our developers. You can say "everyone with access to the system". If you then take that general user you can divide him into different categories, for example after skill (first time user, experienced user, user with hearing disability, expert user), client (integration, mobile client, web client, windows client), access rights (basic rights, administrative rights) or user type (helpdesk, technician, super user, operations technician, developer) or a combination of many of these traits.

Why you specify the user type is that it is made clear to everyone for whom you're building and for whom you are not building. This does not only make it more clear to the developer how UI should be formed but also how business value is calculated - if the sales division wants to target a certain group the business value of stories targeted at that group can be lifted. It is also tactical to give different groups "something of their own" from time to time to make them feel prioritized and seen in the project. It also tells the developer whom they should ask for details - if the user with poor sight is targeted, well, such a user should be able to give some input!

After you've specified user, you say want you want built: for example:
As a mobile client user, I want to be able to view a case address on a map

If it is not self evident why a mobile client user would want that you can add a specification why:
As a mobile client user, I want to be able to view a case address on a map so I can find my way to the location

That is how easy you write a story. But who writes them and how do you store them? And where do you keep the details? To be continued...