Knowing the real needs of users and developing features consistent with this reality are key factors in building successful products. In this article, you will see more details on this topic, especially regarding techniques for writing quality and assertive User Stories, examples and other related topics, which are also brought up in the book Product Backlog Building (PBB), by the authors Paulo Caroli and Fábio Aguiar.
- When did I first hear about User Stories
- Waterfall, Agile and User Stories
- User Stories Format
- Acceptance Criteria
- Breaking stories into tasks
- User interface
- Writing stories with PBB
- User story example
- TAPA to check the quality of User Stories
- Facilitating the writing of good User Stories
- Definition of ready
- Definition of done
- User Stories in Scrum
- User Stories in Kanban
When did I first hear about User Stories
When asked when I heard about User Stories for the first time, an important name come to my mind: author Mike Cohn. He is considered one of the great references when it comes to user stories.
In the book User Stories Applied: For Agile Software Development (2003), Mike Cohn points out that the best way to build a product that attend the user needs is to make use of user stories.
It was he who popularised the acronym INVEST, which you will see in more detail below. For Cohn, it is essential to understand each user, because, from this, there is a connection with the user’s needs and, thus, the creation of valuable products.
Waterfall, Agile and User Stories
The Waterfall Method, also called the Traditional Method, is a management model based on phases, where the end of one phase indicates the beginning of the next. For example: planning, execution, validation and release.
However, for the present day, despite the success in the last century (especially for other engineering practices, not software), the Waterfall model appears to be outdated and risky. The Waterfall sequential nature dictates that the output of a phase is the input of the next phase, therefore creating the all-or-nothing situation, which, unfortunately, required heavy control and management to avoid the typical nothing (or not as planned) scenario.
The obvious disadvantage, of course, is that by making each stage so heavily reliant upon the previous one, Waterfall leaves very little room for catering to dynamic needs. Other drawbacks, however, include any or all of the following:
- lack of flexibility
- rigid planning
- long feedback cycle
- process focused (instead of product and customer focused)
Agile methodologies came to change this reality. With light-weighted approaches, Agile teams aim to build the right product, with incremental and frequent delivery of small chunks of functionality, typically described as User Stories.
Agile teams typically work in short and frequent cycles, with quick planning and fast, user-centered outcome. Another big difference lies in the fact that changes can be made throughout the product development, while in the Waterfall method changes are not welcome.
User stories are an essential for agile methodologies. It provides the means to continuously build and refine the requirement for the work. Something that, on waterfall style, was a generated artifact for the initial project phase. For example: the Analysis phase would generate the BRD (short for Business Requirement Document), which was carried to the next waterfall phase.
User Stories Format
Originally, user stories were born for the purpose of the user requesting the functionality to write it. However, over time, largely driven by the expansion of the Scrum framework, the Product Owner became the primary person writing these user stories and organizing them into a product backlog. However, anyone can (and should) write a user story. By the way, Product Backlog Building (PBB) is a a method (shared in the book) that helps you write good user stories. Find out more in this article and in the book.
3Ws of User Story
User Story is a textual format for the concise description of a requirement, which seeks to answer three specific questions from the acronym known as 3Ws: Who, What and Why.
- Who wants it (role/profile)
- What it is they want (action/activity)
- Why they want it (benefit/reason)
As a WHO (role/profile)
I want to WHAT (action/activity)
So that WHY (benefit/reason)
INVEST
In his book Extreme Programming Explored (2001), William C. Wake shared the acronym INVEST, where each letter represents one of the six important characteristics of a user story: independent, tradable, valuable, estimable, small, and testable.
A few years after this creation, Mike Cohn ended up renaming the letter S, from small, to Sized appropriately, as some people created stories a little bigger, but suited to their context.
- INDEPENDENT: One story does not depend on another.
- NEGOTIABLE: A story captures the essence of what is desired. It’s not a closed contract, conversations and negotiation are welcome.
- VALUABLE: A story clearly describes customer value.
- ESTIMABLE: A story provides enough information for the team to come up with a high-level estimate.
- SMALL: A good story should be relatively small in size to be completed in the shortest possible time and fit into an iteration given the team context.
- TESTABLE: A story must be clear enough that tests can be defined for it.
Therefore, the acronym INVEST helps in writing good stories, with the following questions: is she Independent? Negotiable? Valuable? Estimable? Small? Testable?
3Cs Model
In addition to the INVEST Model, a good user story also consists of three elements, called the 3Cs: Card, Conversation and Confirmation.
CARD: The user story description must fit on an index card, containing enough to identify it. The most common format is:
- As a <role/profile>
- I wan to <action/activity>
- so that <benefit/reason>
CONVERSATION: The main reason for putting user stories in an index card format is that there isn’t much room to write. Therefore, a lot of conversation is needed to clarify doubts and detail the work needed to implement it. Working with user stories means accepting that conversations about work will be ongoing, and not just placed at the beginning when the requirement is initially set. The best documents help us remember our conversations, not replace them.
CONFIRMATION: This is where you determine if the user story goal is achieved. To do this, the acceptance criteria confirms that the user story has been implemented correctly and successfully delivered. Acceptance criteria must be defined for each story before the team starts implementing it. That way, there are no surprises when verifying its completion.
Acceptance Criteria
The Acceptance Criteria is intended to describe how to validate a user story. Generally, a story will have some acceptance criteria, also called ACs (short for Acceptance Criteria).
In doing so, ACs provide a checklist that determines when a user story is done, complete, and working.
From the book Product Backlog Building, we bring the following story as an example: “As a customer, I want to withdraw money at the ATM to avoid the bank line”. Here is a possible list of ACs for this situation:
- Customers with sufficient balance is able to withdraw money from their account.
- Customers without sufficient balance is unable to withdraw money from their account.
- Customers with sufficient balance cannot withdraw money from their account if the ATM does not have enough money to withdraw.
The format presented is compared to a checklist used to verify that the story is complete and working, that is, if it passes through all the ACs. If there are more than five ACs, it is recommended to split the story in two.
Breaking stories into tasks
This breaking of user stories into smaller pieces gives rise to tasks. With them, the development team goes into technical details about how the smaller pieces will be implemented. Unlike stories, the tasks are more direct and with technical language, not following a defined textual format.
Tasks identify something that needs to be done in a story. A few examples of tasks: change fields in the table, create test data for scenario 3, automate data generation script etc.
User interface
The way to describe the interface of a user story varies according to the preference of the team and this can be done in the following ways: sketch (or simple drawings on paper), wireframes, mockups or prototype.
A question that arises is how much of the interface needs to be defined to start working on the user story? The answer is basically the team’s agreement to decide if the story is ready from a UI point of view. The most important thing is that the group is aligned and comfortable with the work to be done.
Writing stories with the PBB Canvas
Product Backlog Building (PBB) shares the PBB Canvas, a tool to help the writing of good user stories. As seen earlier, writing a user story basically answers three main questions: Who? What? Why?
The “who?” refers to the persona. The “what?” refers to the Product Backlog Items (PBIs); and the “why?” speaks to the benefits of the feature. The figures below illustrate in a very simple way how easy it is to write user stories with the help of the PBB Canvas.
The article on MartinFowler.com and the book go into more detail on using the PBB canvas.
User story example
In the PBB book, you will find complete user story examples for a digital product that organises talks and events. Below you will see some details about the description of a product feature with some user stories, acceptance criteria, tasks and interface:
Persona, feature, user stories
Following is a sample feature of the digital product that organises talks and events with its respective persona and user stories.
PERSONA: SPEAKER
FEATURE 1: Publish work
STORY 1.1: As a speaker, I want to publish my talk to make content available.
STORY 1.2: As a speaker, I want to link the external presentation to integrate my talks.
User story, acceptance criteria, tasks
Now, going into more detail for the user story 1.2, with its acceptance criteria, and tasks.
ACCEPTANCE CRITERIA 1
SCENARIO 1: Link presentation across presentation sharing platforms.
Given that there is a valid link on the SlideShare platform
When I associate the external presentation link
Then It will show a preview of the presentation on the screen.
ACCEPTANCE CRITERIA 2
SCENARIO 2: Associate presentation when publishing talks.
Given that the presentation link is valid
When I publish the talk
Then it will show the associated presentation in the published talk details.
TASKS
– Consume the presentation endpoint.
– Create UI to show the PDF file of the presentation.
– Create backend logic to link presentation with published work.
– Change parameter for public or private link.
– Create test data to verify link is valid.
– Change DB to include presentation link.
TAPAs to check the quality of user stories
Even using PBB to generate your stories, you need to check their quality, that is, the alignment between the team on the main attributes of the story. It was with this intention that Manoel Pimentel created the TAPAs technique.
According to Manoel, TAPAs helps to enrich the analysis and understanding of the main attributes of a user story, which form the acronym TAPA: tangible, atomic, precious, accessible.
TANGIBLE: The story is tactile, concrete and specific.
ATOMIC: The story is small and independent.
PRECIOUS: The story solves an important problem for the user.
ACCESSIBLE: The story is clear and easy to understand.
Similar to a meal at a Spanish tapas restaurant, Manoel Pimentel explains that you will eat several tapas, which are delivered frequently. Unlike traditional (not agile) restaurants, which work with a main course that will take longer to be served, and you will probably need a fork and knife to cut it into smaller pieces.
Facilitating the writing of good User Stories
In a session for filling up the PBB Canvas, it is essential to define who will be the so-called facilitating person. Among the facilitator’s missions are: to help decide how long the session will last; tailor the session according to the context and reality of the team and the organization; to provoke the collaboration of all the people of the team; in addition to encouraging active communication by all participants in the ideation, understanding, analysis and creation of the user stories.
The facilitating person can be anyone and everyone who has an interest in helping to build a good product backlog with clear user stories. Usually, someone on the team already assumes the role of facilitator of collaborative workshops. This person is a good candidate for facilitating the session. In this sense, several people shall be interested in facilitating the session, such as, for example, the Product Owner, the Scrum Master, the agile coach, the product manager and the developer.
Definition of ready
The definition of ready (DoR) is the agreement between the team and the PO that indicates when a user story will be ready to be pulled into a Sprint, that is, when it will have enough information to go into planning, execution and delivery.
People often say that: “This item is ready to start work”, and usually this indicates that the team:
- Has the information needed to work on the item;
- Understand the why of the item;
- Can show completion of work;
- Identifies how the item composes/relates to a functionality;
- Agree that the item fits in a Sprint.
For each Product Backlog Item (PBI) candidate for the next Sprint, the team verifies that:
- It is represented by a user story.
- It is covered by acceptance & BDD criteria.
- It is mapped to an interface (when needed).
- Its dependencies are identified (if any).
Product backlog refinement must be ongoing. It is worth remembering that the use of the definition of ready and the definition of done is not limited only to Scrum, as it is also a very useful practice when we are working with Kanban and other agile methods.
Definition of done
The definition of done (DoD) is the agreement that demonstrates the quality of the work item produced, in which “done” proves everyone’s satisfaction with the work performed. part of the product increment.
With this, in relation to each item considered ready, the team demonstrates that the item:
- Delivers a product increment.
- It contemplates the established acceptance criteria.
- It is documented for use.
- It adheres to coding standards.
- Maintains product performance indices.
These are examples of DoR and DoD. It is important to emphasise that these are team agreements. Therefore, you can use ti as a start point, but make sure to define it with your teammates.
User Stories in Scrum
Scrum is considered the most famous agile methodology and is based on the concept of Sprint – short cycles (one or two weeks) – to maintain the cadence of a team. Each Sprint starts with a planning meeting (Sprint Planning) and ends with a meeting to review the work done (Sprint Review).
Prior to Sprint Planning, desired product increment is detailed in user stories. For this construction, the PBB Canvas will help to break these features into stories.
That way, during the Sprint, the Scrum team works on the user stories. In Sprint Review, the team will check the progress of these stories, their features and the product increment.
The Scrum teamworks on a continuous cadency. The increment is delivered, and the team works on the next features and user stories for the next product increment. To work effectively with user stories is to continuously create, refine (PBB Canvas help you with this part) and deliver quality user stories.
User Stories in Kanban
Another widely recognised agile method is Kanban, created by David J. Anderson. It is widely used for managing the workflow of an incremental and evolutionary process. Thus, it is possible to have a shared view of all phases of the workflow, the people and the tasks to be performed.
Kanban recommends limiting work in progress (WIP). As a result, a “pull system” occurs, that is, a new item is only “pulled” to the new stage when there is available capacity within the WIP limit. This makes for organisation, planning, agility and does not overload the team.
In a simplified Kanban board (To do -> Doing -> Done), you will assemble and divide the next product increment into user stories (To Do), the ones that are in work (Doing) and, in the last column, the user stories that are already ready ( Done). When you finish all the stories for the increment, you open space on the board and pull up the next feature or product increment and its user stories (created and refined on the PBB Canvas).
———————————
Much of the content shared on this article comes from the PBB book, a little bit from the Lean Inception book and, a little more, from other posts and content form the Lean Delivery with agile metrics training material.
Did you like this content?
>> Then check out the PBB book and PBB Training.
>> On the PBB book page you will also find excellent material (DoR, DoD, ACs etc) to download in PDF format.
On Caroli.org there are, among other things, various materials related to the topic. Access now and continue your knowledge and learning process, as well as building a successful product.
