The User Story format is often used by Scrum teams to document requirements. It’s a short syntax that sounds totally simple, but when we sit down and try to fill this syntax with life, we quickly realize that it’s not that easy. Some of you may have stumbled across user stories that somehow sound “artificial”. So what is it about this little sentence? Why do so many people use it? And do Scrum Teams have to document requirements in the user story format? Don’t they otherwise make a “real” Scrum?
What does the Scrum Guide say?
If the User Story format is mandatory for Scrum Teams, then it should be in the Scrum Guide. Pragmatically as I am, I entered the words “User Story” into the text search of the Scrum Guide and didn’t get a single hit!
The Scrum Guide only talks about product backlog items, not user stories. Basically we can say that Scrum Teams don’t have to use the User Story format according to Scrum Guide.
Conversely, it can also not be said that Scrum Teams that do not use this format do not make a “real” Scrum. The question remains, what exactly are product backlog items? Does the Scrum Guide tell you how to write them?
Product Backlog Items
The Scrum Guide describes product backlog items as follows:
“The product backlog lists all features, functionalities, improvements and bug fixes that will make changes to the product in future releases. A product backlog item contains a description, order, estimate and value as attributes.”
Accordingly, it is not defined how a product backlog item should be described, it is merely stated that there is a description. According to the Scrum Guide, a product backlog entry has four attributes:
So use formats to write down your product backlog items that make sense for your context. These could be simple texts, bullets or hypotheses to explore.
If the User Story Format is not defined in the Scrum Guide, where does it come from?
Origin of the User Story Format
The User Story format comes from Extreme Programming, also known as XP. Kent Beck invented it and uses stories (he didn’t call them “user stories”) to describe a user’s real stories. What exactly does Kent mean by that? Kent refers to the narrative when a software user describes a problem as a user story. But he doesn’t speak of this little syntax as we know it today.
The user story syntax is by Rachel Davies of Connextra. Rachel probably noticed that many user stories were very long. She wanted to have a short and crisp description that invites people to a conversation. Therefore she had the idea to describe the “role”, the “feature” and the “benefit” typically in the following syntax:
- As “role” I would like to have “feature”, thus “benefit”. Or also:
- In order to “achieve utility” as “role” I want “feature”.
And why is writing user stories so hard now?
Basically, writing user stories is only difficult when we don’t have a user story, but try to press a request into this format. So if you have trouble formulating a user story, ask yourself: Do I know a user who can tell me a story about this topic? If so, go and ask him if he can formulate a product backlog item for you. In this situation it can help you to use the User Story syntax together as an aid. Because the syntax raises three important W questions:
- Who wants that?
- What does this user want?
- Why does this user want that?
If a user can answer these three questions, he has really thought about this requirement and can explain concretely what he wants and why this would help him. Our job as Scrum Team is to understand this or to help users answer these questions.
As Scrum Teams, we can validate the question that who wants to have it, using it: Is this user really in our target group? Or do we produce potential unnecessary functionality and thus generate waste (for this target group)?
Or we can use these conversations with our users as input to create personas. Personas help us as a team to document our knowledge about our users and to share it with other stakeholders.
Often, real user stories are very big for development teams and are more like Epic: something too big to do in a sprint. In this case, it can help to use the “what” as the headline and further decompose the user story (we call the product backlog entries small or user story splitting).
The question of why helps us to uncover backgrounds, problems and needs. This allows us to gain a deeper understanding of the situation and ensure that our product really adds value for users. Product owners also use the Why to validate whether this will pay off on their product vision. If it doesn’t, I have to think about it as a product owner: Does it make sense to adjust my vision or does this user story really not belong to my product?
Conclusion
A product backlog does not consist of user stories but of product backlog items. User stories can be a possible form of product backlog items. Basically, entries in a product backlog are called product backlog entries. Product backlog entries have 4 attributes, description, order, estimate, value.
User Stories only make sense if it is really a story a user would tell you. The user story syntax asks 3 W questions, but it’s just an invitation to a conversation where we can get more knowledge about a topic and a user. The value is created “before the paper”.
And product backlog entries can be written by anyone and brought to the product owner.
That’s what our readers think
In a nutshell, Agile is about communication, teamwork, collaboration, adaptability, iteration, feedback, and of course, agility! The development initiative is broken down into efforts of short duration and change is not only expected, it is embraced by all stakeholders. To successfully implement Agile, an organization must embrace its concepts and philosophies at all levels.
Once requirements were complete and development had begun, change was just not something that was easily entertained. Let’s keep in mind that concepts such as Continuous Integration and Configuration Management were unknown and use of source control repositories was not as mainstream as it is now. A change in requirements was just quite difficult to accommodate and was generally frowned upon.