As a Business Analyst Coach, I often get asked how to write a user story. In my experience, Agile BAs can write a user story that they understand perfectly, but does not take into account the rest of the team’s different communication styles and knowledge. For example I often see user stories that are ‘tech’ heavy, and while this information must be included I usually suggest it appear as a subtask requirement instead.
It got me thinking that it would be great to have a list of what makes a first class user story.
So I looked around for some inspiration on how to write a user story with clout and clarity. I found this great article from Judith Mary Khan, where she calls for a user story with ‘qualities’ and that’s exactly what will help my Business Analysts clients.
Here are 12 Tips on How To Write A User Story With Quality
- A great headline reads like a story, not a puzzling technical paraphrase.
- A description that cuts to the chase and is readable by all scrum team members.
- Use story notes. If this is available, capture and describe aspects and details beyond the description.
- Capture the tasks involved for specifying the requirements, the work of the Developers, and the criteria for QA activities. My current team makes this quick to grasp with prefixes to indicate which team member is responsible, such as ‘DEV’, ‘QA’, etc.
- Clear acceptance points or criteria are written so that any business analyst can walk through the deliverable and give it a yes or no to pass for acceptance, or to pick up the workflow. It should be cross-team member ready.
- A workflow that makes common sense and uses verbiage that can be readily understood. This workflow should be visible to all users, and permissions granted only for those who are in the appropriate role to select that workflow step.
- The right screen shots should be attached, but only if needed.
- Attachments can serve as directly related to fulfillment of the story, and become a powerful reference tool in future use when investigating the history of a feature or whatever was important to the story. Meaningful and supporting attachments can also guide the knowledge transfer when new team members join.
- Comments should be direct, and to the point. This is all too often overused, for comments that do not need to be captured and reread. Valuable comments are readable, complete, and understandable. Any ‘next steps’ or action items that come out of a comment need to be clearly stated.
- Use the story points to track, communicate, and reflect the best estimating available from the team. A lot of skill goes into good estimating and the various team members have a lot to offer. Make sure that all voices are heard, especially from QA and UAT.
- Use your story to facilitate prioritization. Keep the ranking within the story itself. This can then be ready to use when reviewed, reported, analyzed for metrics. The PM, and the dashboards that can be created will thank you.
- More… employ the elements that will make it valuable to your team and efforts. Agile allows options, and as the BA, you can facilitate it.
BA Simplified can help you to discover the most critical business analyst skills – in a simplified form so you can get the edge. We are here to make becoming and excelling in business analysis as simple and easy to understand and implement. We also help organisations to implement effective business analysis practices in delivering successful projects.
Let us know if you found this useful – and what you would add. We’d appreciate the feedback!