There must be 50 Ways to Write a Great User Story

The user story is the center-point for the Agile business analyst to perform work. From the story, everything else can be facilitated, requirements definition and communication, development and QA tasks that will bring it to completion, tracking and reporting for the team, management, and even the customer, and even knowledge transfer for future team mates. All of this is possible with the well-written story.

During the time that I have worked as an Agile BA, I have seen stories used in a broad spectrum of manners, those that are completely cryptic in what their purpose is, those that read more like random defects recorded by IT and/or non-IT people, those that are largely dependent on tribal knowledge, and those that are concise, clear, and deliver all the important pieces to be truly useful to all the team, as well as non-scrum team stakeholders.

I recently decided that while the story can be used in numerous ways, a good story will have certain attributes. Check the list that follows and see if there are more ways to write a good story. In an Agile team, the flexibility will be built into it by doing what makes the most sense to your unique project and your unique team. The rigueur of waterfall methodologies will not limit the Agile BA to a strict set of requirements to fulfill in getting acceptance of the requirements documentation. It will also expand the BA’s capability to communicate across teams and simultaneously contribute to the library of project documentation.

Related Article: User Stories – You Don’t Have to be Agile to Use Them!

Keep in mind, as the owner of the user story, seek to communicate efficiently, and with clarity. Do not bury the meanings, purposes, objectives in verbiage that is not readily accessible to the spectrum of stakeholders that will be the consumers of the story. In depth technical details, and even details of business process information can be included in the story, but as a subtask requirement, or an image or attachment to the story. Keep your headline reader ready! This applies to Developers and other technical team members to the business customer and executives. Make your handprint on the story by offering clarity, versus one that furthers confusion.

How you write a great story is up to your own project and style, but make sure it has these qualities.

Here are a few ideas:

1. A great headline reads like a story, not a puzzling technical paraphrase.
2. A description that cuts to the chase and is readable by all scrum team members.
3. Use story notes. If this is available, capture and describe aspects and details beyond the description.
4. 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.
5. 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.
6. 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.
7. The right screen shots should be attached, but only if needed.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. More as you can think of them!

All of these pieces work interdependently to define, communicate, and deliver requirements. The Agile BA is the one who ushers the story, facilitates the collection of story components, and gives it a consistent tone, style, and voice.