10 Tips for Writing Effective User Stories

Source

In the world of agile software development, all business requirements should be expressed in user story format, and any requirement which cannot be documented in this format is probably not a business requirement or there is no business value. In other words, user stories are software requirements formulated in everyday language that outlines how they will generate value and for whom. User stories live in the product backlog and it represents a standard of capturing feature wishes regarding the product.

Stories are often written from the perspective of an end-user and in the beginning were written on index cards or sticky notes, stored in a shoebox, and arranged on walls or tables to facilitate planning and discussion. Nowadays, the card is typically a card in a user story map that will be transformed into a ticket in an issue tracker (backlog).

Who owns and who documents the user stories

It’s the product owner’s responsibility to make sure a product backlog of agile user stories exists, but there are often doubts about who can write them. The correct answer is “anybody” who has clarity on the requirement. In lots of projects, the business analyst is the main person who is documenting user stories. Throughout a good agile project, you should expect to have user story examples written by almost each team member, but in the end, the product owner should, however, review and accept them.

Epics versus user stories

Agile teams use epics and user stories to confer with requirements that deliver value to end-users. The difference between user stories and epics is that user stories are small, lightweight requirements while epics are larger. In the same way that a river could be a large stream, an epic could be a large user story. Epics are decomposed into smaller stories that fit more readily into one iteration. Additionally, new stories are written and added to the backlog at any time and by anyone.

Anatomy of user stories

The user story structure serves as “training wheels,” reminding people in conversation about user stories to pay attention not just to “what” but also to “why” and “who.” Below is a visual of the official format of a user story in Agile:

User story format

The lifecycle of a user story

One of the founders of the Extreme Programming methodology discovered a great way of thinking about user stories — the three C’s framework. The detailing of a user story card is done through multiple stages of the refinement process. These are broadly classified and known as the 3C’s introduced by Ron Jeffries, which stands for Cards, Conversation, Confirmation:

• Card: At this stage, only the purpose of the card is highlighted with no or only a few details on the actual expectation
• Conversation: At this stage, agile team members from the development side but also from the product side discuss the scope of the card and detail the card by providing estimates
• Confirmation: At this stage, user acceptance criteria are a specific part of the conversation. It’s the agreement on how the user story will be tested, and whether or not the main business need has been fulfilled.

💡 Pro tip: Each C is important, but the conversation is what lies at the heart of it all.

INVEST in good user stories

Writing requirements in a user story format was a practice first adopted in Extreme Programming by Bill Wake, who first formulated the INVEST criteria for Agile user stories. In his vision, stories act as a pidgin language where both sides can agree enough to work together effectively. You don’t know what a pidgin language is? It is usually used for trade, which allows people who can’t communicate in their native language to nonetheless work together. User stories act like this. For sure customers or users are not able to view a software system in the same way that programmers do.

One of the initiators of the agile movement said that “a user story is a promise for a conversation.” (1)

In other words, it is a business statement of what is needed and why. The business and development team(s) will follow some common guidelines then the stories will become effective.

Source

According to Mike Cohn, user stories will become effective if both business and development team(s) follow some common guidelines. The acronym “INVEST” can remind us of the main keywords we need to take into consideration when writing user stories.

• Independent: User stories should describe non-overlapping bits of functionality. Dependencies between stories cause delays. A user story couldn’t be complete until all the dependent stories are user-ready.
• Negotiable (and Negotiated): stories have flexibility; there’s room for a collaborative definition of success. Treating the story as an evolving conversation between the product owner and the development team builds a shared understanding and harnesses everyone’s expertise: the product owner knows the value that the user story will bring to the users and on the other side the development team knows the best way to implement that need and make it available for them.
• Valuable: Stories’ value makes sense from a customer or end user’s perspective. In Agile, the main goal is to deliver valuable working software. Each user story needs to explicitly state the value it will bring to the product. Some important questions you could have in mind when writing user stories are: “What user needs does it meet, what risks does it mitigate, what costs does it save, and what learnings does it allow? How will this story help achieve the product vision?”
• Estimable: The team can estimate the difficulty of the story (at least to a rough level). Product owners need to know the size so they can prioritize the stories that give the most value for the least effort.
• Small: The story is small enough for its purpose. For implementation, it can be completed within a sprint. For longer-term planning, the story is larger. Agile works in sprints of a minimum of 1 week to a maximum of 4 weeks, so you can get fast feedback from users. Sprints require small stories so the smaller the story, the more likely it will be to deliver value by iteration’s end.
• Testable: The customer, developers, and testers can agree on what the story means precisely enough that tests can be created based on the main acceptance criteria highlighted. At the end of implementation, the main question for all team members should be: “All the acceptance criteria for this story were met?” If there isn’t a ‘Yes’ or ‘No’ answer, then that story cannot be tested by the quality assurance engineers and neither by the product owner.

💡 Pro tip: If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite.

Top 10 tips for writing effective user stories

1. Start with epics.
2. Write the stories from a user perspective by following the user story template, keeping the INVEST principle in mind.
3. Write user stories collaboratively.
4. Refine the stories until they are ready.
5. Add acceptance criteria by following the “Gherkin model.” (2)
6. Keep stories visible and accessible.
7. Besides user stories, consider the user journeys and interactions, the visual design, and the non-functional requirements of your product.
8. Keep your stories small and independent, which will help them flow through the work process.
9. Keep your stories valuable to end-users, and ideally testable so you know with confidence that they’re done and working properly when delivered.
10. Keep your stories estimable, or small enough that you don’t need to estimate them, and negotiable, meaning they’re not set in stone as written.

Top Takeaways:

• User stories are written in everyday language and are meant to provide a basic framework for a conversation with the customer, and that conversation will provide the developer with what they need to know to implement the story.
• Refinement sessions make the user stories effective as per the conversation between development and product.
• User stories should be written in the correct format and acceptance criteria should be documented.
• The acronym INVEST helps in remembering to use a widely accepted checklist to assess the quality of a user story.
• Don’t write novels about your user stories. Capture the three C’s by sticking to the point.

Properly written user stories provide a solid basis for communication and collaboration — emphasizing what matters most to the user. User stories provide a wonderful way to define your product with clarity and by taking into account the ten tips mentioned above you’ll be able to write effective user stories for your product.

Sources:

1. Agile Software Development: The Cooperative Game, Cockburn, Alistair, 2001.
2. Domain-specific Languages: Parsons, Rebecca, and Martin Fowler, 2011.
3. “Effective User Stories — 3C’s and INVEST Guide.”
4. “Essential XP: Card, Conversation, Confirmation,” Ron Jeffries, 2001.
5. “INVEST in Good Stories, and SMART Tasks,” Bill Wake, 2003.
6. User Stories Applied: For Agile Software Development, Mike Cohn, 2004.