A popular term you will come across when working in agile is the “user story.” For the uninitiated, a user story is a technique of expressing software requirements in a specific format, usually:
As a < role of user >, I want to < perform an action >, so that < goal of user >
This adds more detail and description, and it’s sure to include the real need of the user when expressing the requirements.
For agile teams, user stories are a typical way to begin a conversation about a feature. But issues arise when we stop adding more beyond the one-line user story format. Most agile teams are crippled by incomplete, ambiguous and vague user stories that lack depth and details.
In my experience, there are some ways we can ensure that the user stories we craft are usable and valuable in all aspects.
Get TestRail FREE for 30 days!
The INVEST Principle
INVEST is a popular mnemonic used in this requirements gathering. Our user stories must be:
- Independent (of other stories and dependencies or conflicts)
- Negotiable (how to implement a feature is not discussed in the story)
- Valuable (to the software and its user)
- Estimable (in terms of effort and time)
- Small (implementation is possible within a sprint or iteration)
- Testable (independently testable in functional and non-functional aspects)
So, when writing a user story, keep in mind the things we look for in ideal user stories and try to incorporate these attributes.
The 3 C’s of a User Story
Another widely adopted practice calls for having the three C’s of a user story:
Card is the physical card we write a user story on. If the team is not using a physical card, then it could be a virtual card, sheet or task in your test management system.
Conversation is the step where the entire team has a conversation about what the single line of the user story means and what is expected from the implementation. Any related mock-ups or diagrams are shared, and developers and testers ask questions until they understand it all. These details are now a part of the user story and are noted within the task, sheet or card for further reference.
Confirmation criteria are then decided upon in consensus. They will form the acceptance criteria for the fulfillment of the user story. Developers will look at this list of confirmation criteria when deeming their story done, and testers use it as a basis for designing their acceptance tests.
Benefits of this approach are that we get everyone to have a conversation and achieve consensus on what the user story is supposed to do. And once the discussion is done, everyone can be at peace knowing that nothing will change or be added into the context of this user story as long as the understanding remains the same across all stakeholders.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Learn from Experience
Having solid user stories was very important to my team when we were working within the strict time frame of a sprint. We were always pressed for time and wanted to get things done fast. But that was nearly impossible when dealing with one-line user stories that meant different things to everyone, especially when one story changed several times during the course of the sprint. Another challenge was having to pull things from the product backlog in our sprint planning meeting and estimating them without having complete details about them.
After learning from our experiences, we adopted the following measures over a number of sprints:
- The product owner would present the tentative user stories for a sprint before the sprint planning meeting. These stories would have to be presented with some detail and preparation so that questions from the developers and testers about the feature were answered, not leaving much room for “We’ll get back to you on that” with surprises later. They would usually support using mock-ups and UI designs and give us a solid footing to begin with.
- We created Jira tasks for each user story. The user story was the title of the task, and the details and discussion points were added to the description.
- After that we had the estimations of these user stories to plan out our tasks and work. All estimations were based on the user story state as it was, so it was agreed that any change in scope or addition to the user story later would be based on the sole discretion of the person working on it and may or may not be accommodated within the stipulated time. We would then plan our sprint backlog with stories, and even plan their priorities and sequence of delivery within the team for testing and cross-dependencies.
- Meanwhile, the product owner prepared for the upcoming sprint’s user stories in a similar fashion while we hacked away at the tasks at hand.
Writing good user stories is a craft, and it forms the basis of success for any agile team. By placing emphasis on clarity, transparency and continuous communication, we achieved the best user stories for our context.
Using the above tips and tricks, any team can craft user stories that are understandable, usable, complete and valuable, which any agile team will surely love.
Nishi is a consulting Testing and Agile trainer with hands-on experience in all stages of software testing life cycle since 2008. She works with Agile Testing Alliance(ATA) to conduct various courses, trainings and organising testing community events and meetups, and also has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
Test Automation – Anywhere, Anytime
