PART 2
User stories in practice
Let’s go over Ron Jeffries’ 3Cs and check the characteristics of a great user story with a technique called INVEST.
Welcome to the second episode of the User Story series! In the last episode I told you a story about the user stories and today we will put that theory into practice.
3Cs by Ron Jeffries
3Cs from Ron go like this: Card, Conversation, Confirmation. Let’s focus on those three things now to check out the process of creating user stories in practice.
1. Card
The card idea comes from the library cards that we used in the pre-internet era to look for books. They contained the author, the title of a book plus a short summary about it. Ron thought that similar cards could be used to write a short summary of the new functionality of a software system. The Card triggers the conversation. It can contain the template “As a user, I want, so that…” but it’s advisable to give it a short self-explaining title. To avoid having a backlog looking like this:
What’s more, has it ever happened to you that during the daily someone was referring to a story by its number? Rather than by its title? That’s when we know that we killed the story, don’t we? This might be because the title was too long and confusing, check the picture above. We can solve it easily by adding a concise and self-explaining title.
For our example from the first episode:
As a mobile phone user, I want to check the weather forecast for my current location so that I don’t have to look it up every time I travel to a new place.
The title for this story could go like this:
“Current location for weather forecast.”
2. Conversation
We said that the Card above could be a starting point for the conversation the product people would have with the development teams to achieve a shared understanding of what to build. So they meet and tell stories about who will use the product, what they want, and why. First, focus on what matters most, the implementation details will come later.
Why should we build it in the first place? Think about what will have the biggest impact on your business and the best outcome for the users.
Why do the users want it? And why do we as a business want them to accomplish it? What’s in it for us, what’s the business value?
With that, you build the minimum viable product (MVP) to check what’s the minimum and useful in the market.
If you have a big idea in mind, you could share the objective, the big idea with the team, and collaboratively come up with the stories for it. All of this during a user story mapping workshop. I’ll talk about it in the next episode, as it is a great way to engage the whole team in the creation of the product. For smaller ideas, after the conversation, we move on to step number three.
3. Confirmation
Confirmation serves to record what has been discovered during the conversation and agree on how to verify it works. For instance, by adding Acceptance Criteria to the story.
INVEST
How do we make sure our story has all it needs to be pulled to the next sprint? I talk more about the refinement in another blog post here. Now, let’s see a simple technique that will help us make sure our story is ready. It’s called INVEST and it’s s an acronym that defines six characteristics of a great story:
- I — Independent
- N — Negotiable
- V — Valuable
- E — Estimable
- S — Small
- T — Testable
Let’s see another example of a user story and check if it meets all of these characteristics:
As a lottery participant, I want to enter my lottery number on the website so that I can check if and how much I won.
Independent means it can be done on its own — has no blocking dependencies. For example, we don’t need to login to the system to verify if our number is a winning number, which means it can work on its own with what we already have in the system.
Negotiable… and Negotiated — what’s in the user story is not written in stone, it’s living documentation that can change when we discover more during the development. Then the development team will negotiate it with the Product Owner.
Valuable means providing value for the customer, hence the “As a user I want” and not “As a PO I want” or “As a developer I want”… unless you build tools for POs and developers.
To make it valuable we want to think about the story as a cake. You want to cut the cake so you have a taste of all the layers and not just the whipped cream. The same goes for software development, you want to feed your user with a taste of all the platforms together and not just backend or frontend. We don’t show the user a dummy button saying “Check if you won!” if there’s no logic behind it and the button doesn’t work. We need to ask ourselves:
How can we provide value to the customer so they can start using the new feature directly after our story is done?
Estimable so it can be estimated, usually the smaller the easier to estimate, the more testable the easier to estimate. Why estimate? If we can estimate a story, it means we know enough about it and it is feasible. We don’t estimate what we don’t know. If we cannot estimate our story, it definitely needs more discussion, more detail, or more research.
Small. In Scrum, it means fitting into one Sprint but can be less. The smaller the story the easier it is to grasp what it’s all about. The small characteristic goes very closely with the valuable one. If you want to slice the story into multiple smaller stories, you need to make sure all of them provide value for the user. Like the pieces of a cake, you are serving to your guests at your birthday party - all of them with the taste of all layers that are like our software platforms.
Now, imagine our lottery story doesn’t fit into one Sprint. What can we do? Maybe it can be divided into two smaller ones and each of them providing value for our users?
1. The first story would check if I won or not:
As a lottery participant, I want to enter my lottery number on the website so that I can check if I won.
The title could be:
Lottery participant is able to check if they won.
2. The second story would check how much money I won, with the precondition stating that I have a winning number:
As a lottery participant with a winning number, I want to enter my lottery number on the website so that I can check how much I won.
The title could be:
Lottery winner is able to check the prize amount for his number.
This way we can provide value to the user faster, right after the first story is completed. And we can learn sooner how many users are interested in using the new functionality.
Testable. If we know how to test it, we will know when it’s done. A common practice is to add Acceptance Criteria to the story. These are some use cases that determine that the software does what it is meant to be doing.
The Acceptance Criteria provide the functional scenario, and the testing part consists of checking the edge cases, “sad path” scenarios, non-functional tests (e.g. performance) etc.
Each story has some specific Acceptance Criteria that help the teams grasp what goals need to be achieved by the new functionality. Then, there is the Definition of Done that the team agrees on, that sets some generic criteria that each user story needs to meet before going live on production.
Let’s start by adding some Acceptance Criteria to the first story from our lottery example:
As a lottery participant, I want to enter my lottery number on the website so that I can check if I won.
The Acceptance Criteria could be:
- If the number is a winning number, the user should see a message: “It’s your lucky day, you won!”
- If the number is not a winning number, the user should see a message: “Try again, I bet next time you will win!”
For the second story:
As a lottery participant with a winning number, I want to enter my lottery number on the website so that I can check how much I won.
the Acceptance Criteria would be as follows:
- If the user won, the winning amount should be displayed in currency format.
- Users can only check winning numbers from the past 30 days, etc.
Given/When/Then is a Gherkin language format to write Acceptance Criteria and automation tests that is derived from behavior-driven development (BDD), e.g.:
Given a user has a winning number, when they enter the number on the website, then the winning amount is displayed in currency format.
It is especially useful if you run a tool with automatic tests, like Cucumber. Again, just as with the user story template, it’s optional to use this format.
Definition of Done
If our lottery page should be mobile-friendly and available in three languages, those generic requirements could for part of our Definition of Done.
To summarize
User Stories are made to encourage conversation about the product within the teams that are focused on the three most important things: who will use the product, what will they do with it, and why.
Splitting User Stories can be complex. But worry not, you will master it with practice. There are a lot of techniques that can help you, I can recommend you to read Mike Cohn’s book “User Stories Applied” and watch his Better User Stories video series.
Stay tuned for the next episode from the User Stories series about User Story Mapping!
