Writing effective user stories and work items
I believe with some basic principals in mind, everyone can write better user stories and work items.
So often i find the user stories and work items being written to vague and general, in a way that the allow for the scope to change or widen as we go. It may not describe the expectations at all, or communicate the outcome expected of the work item. I do not mean the scope should never change, because it will and it certainly should. If the scope change it should result in changing the user story to represent the new or changed scope, or another user story which cover the new aspects.
The title should describe the user story and its scope clearly, in a way that you can know when it is completed. Meaning it should not be vague and wide, even if the description is clear and with a defined scope.
Many stakeholders only read titles and when they are vague, they will for sure make their own assumptions and have expectations that exceed the scope. You can of course pin them for not reading the description, but their experience is already compromised. Even with good titles this will be a challenge, but their expectations are much closer to what they get and will by the title see if there is a need for clarification.
Imagine what expectations you create when a story have the title “Translate to Norwegian” and status is completed, some would assume that now everything is translated. What a drawback when the stakeholder find that only the captions was translated, when he infract expected captions, metadata and content to be in Norwegian. A better title would then have been “Translate captions into Norwegian”, or “Translate captions into Norwegian for …”
Another thing that happen when the title is vague, is that the scope tend to change a lot as we go. Because of the title and expectations created by the title alone, project managers as well as the stake holders will continue to change and add expectations which widen the scope. This way you never know when it will be completed or when expectations will be met. These changes should maybe take place, but as changes or new stories and not as mutating stories.
The description should first of all communicate the outcome we want to achieve, by telling who, what and why will get you fare. Many (including my self) use the format “As a … I want …, so that ….”, but why should you use it?
This format help you communicate who will be affected, what want to achieve and way they want so. The simple sentence help ensure that everyone involved works towards the same outcome, it allow to work proactive and ask the right questions.
Now assume that you write the description as a script for how it should be implement, without defining your preferred outcome. The team would most likely be working reactive, and limit them self to the script as robots. They have no way to challange you, or proactively look for and suggest a better way. Nor will they be able to test that your script actually will result in the outcome, or expectations stakeholders are looking for.
After defining the outcome I add a section for defining the expectations, not just the obvious but any which are mentioned or answer to a question. The expectations could be a bullet list explaining some constraints, opinions, preferred solutions, script step by step or whatever is needed. I like to update this section whenever we clarify a new question, or receive new information (with the scope in mind of course).
As a user of Ford C Max I would like my car to open the rear door automatically when swiping my foot below the door,
so that I do not need to put my bags down to open cause they may get dirty.
- Sensor for foot swipe is expected to cover the whole area between the tires
- Door should stop in case it meets any resistance, so that damage is avoided to the door or people behind it
- Should make a sound to alert, before it opens
- Should be a delay after making the sound, so that the user may take a step back before the door opens