So we started with User Stories. But what is the best way to write them down and on what? What tracibility do we need to keep?
The User Voice
One thing a user story breathes is the way it is written by many people. They keep the focus on the way a user would tell it. Why? Because the user understands your product backlog better when reading a story as if it was told by himself. Or rather, he feels ownership of the list better. Much more then some requirement document which has certain semantics which he does not understand and doesn’t want to understand. He feels it doesn’t belong to him. So what is the format? Most people tend to use the following:
As a <role>, I want to <goal> so that <reasoning>
The last part is something people tend to not put in requirements document but it puts the focus on what value it will bring. Making it easier to prioritize between each other. You can compare the values competing stories bring when deciding which one to put in your sprint.
A benefit of putting the role first is the ability to order your list (if you keep it in Excel for example) and you will see the stories grouped by role. Could be handy.
Other thing to note is that the story still is a reminder for a conversation. So you need to communicate with the role written down in the user story. If you don’t have access to this role (for example a visitor group of your website) then decide which person in your organization can act as an acceptant for this story. So who will mark the story as done. Checkout topics on the web about user proxies. He or she needs to know the user. An example would be the marketing or sales department who visit the users a lot and have a generalized image of the user.
If you keep it strict you will also notice that keeping the user story as a reminder for conversation will make the difference between a task and a story you still need to discuss more simple. So, if there is nothing to discuss about the story then it’s maybe to small.
Minimal Marketable Feature
In some product development companies there often is a concept called MMF. The minimal set of features that needs to be implemented before the customer will agree that the functionality is complete (not when it will bring them value, which probably is sooner). Keep in mind that user stories aren’t aimed at this set. So possibly you need to group some stories and mark them as a minimal marketable feature.
The format is verbose
Some people find the format to be lengthy and unwieldable in a project and start to use a summary as a hint to the story. If you do this (and have thought about the consequences) then it probably is the best to include the role and the goal. Maybe like the following?
As as Support Employee I want to process a certificate request electronically so that I can do my work 2x faster
Converted to a title like this
Support employee processes certificate request