What A User Story is about
A User Story is the most widely used Agile Practice for capturing needs and requirements and describing Product Backlog Items. For some time I wonder if the name of the technique might be somewhat limiting. The focus sometimes is too much on using the proper technique and we lose the whole purpose of using User Story.
The purpose of using a User Story is to capture natural conversation about what needs to be built in the product from the user point of view. It should provoke or later capture conversation between the one who wants the feature and the one who will build it. The key is to understand intention and create best possible solution with the known boundaries of architecture and technology. When Development Team understands why the use wants it and what the user wants to achieve they can come up with set of possible solutions.
User Story in practice
Recently I was asked to review and tune up User Story written for online banking system. The person who wrote this was a very ambitious Business Analyst. The User Story goes like “As the logged in user I want to see loan advertisements to buy more loans.”
Looking from the technical point of view it was perfect. While using any technique you should use it as it was intended to get the results you expect. It’s great to use the User Story template As <a user>, I want <feature>, so that <problem to solve, need> + Acceptance Criteria.
We have all the three parts covered and Acceptance Criteria was also there. With most of products there will be different user groups. Therefore it is good to group them into segments and use a representative of the segment in discussions. Very useful agile practice here is to create personas. This way we decide users in groups and we still have and easy to understand representation of the user group with name and characteristics. Here we have a pretty abstract group of users called “logged in user”. Which is fine for that purpose.
However, when you read it you may feel it sounds a little bit odd. Does it sound like a natural conversation? Which user would really ask to be presented with more ads online? Actually I found out who wants it and it wasn’t a user, but it was the marketing manager. So if the marketing manager want’s the feature we should start off with “As a marketing manager I want ...”. Now the real User Story sound like “As the marketing manager I want the logged in user be presented with advertisements about loans to get more sales”. Now it makes sense, doesn’t it? Development Team will clearly understand what needs to be built and why.
But we have marketing manager in <a user> part. Marketing manager is not really a user of the application. She is a stakeholder.
Stakeholders are more than users
In the Scrum Guide we have stakeholders mentioned but don’t really define it. So who is a stakeholder? It depends on your context, but think of the user groups, the sponsors, the regulatory and people who hope to benefit from the product. Now think for a while what does it do to your User Stories and the whole Product Backlog. It will make more sense and it will be more complete. You can deliver more value when you think about satisfying needs of the stakeholders.
What does using stakeholders in a User Story do to your Product Backlog refinement? You should invite the marketing manager who wants it to clarify details. Now you immediately know who is the right person to talk to. Perhaps she should write the user story in the first place, not a business analyst. Even if, definitely any further refinement should be done with here.
When using any Agile Practice you should use it as best you can to get the results you expected. It helps to understand the intention behind the technique to do a better job with it. With using User Stories you need to think about the stakeholders not just users of the product. And that can change a lot.
Should we change the name of the technique? Probably due to the popularity of it it’s too late to do that globally. But it’s not too late for you to change it when you are using the technique with your teams. At least keep in mind how to use it to it’s full potential.