Histoires d'utilisateurs et alternatives
par Avi Schneier et Tom Bullock | August 26, 2020 | Blog
If the Sprint is the heartbeat of Scrum, the Product Backlog is its backbone.
To be effective, a Backlog must be comprised of individual items written in such a way that the team understands not just what work must be completed, but why.
For this reason, many Scrum Teams use templates to write backlog items. These can look like Mad Libs for professionals to an untrained eye.
Take the format known as a User Story (we describe the formula below). This formula is so popular that you may refer to individual items in your Product or Sprint backlog as stories. “I want everybody to remember something before we even start talking about formats,” says Scrum Inc. Principal Consultant Avi Schneier, adding that these formulas “aren’t officially part of Scrum. They don’t appear in the Scrum Guide.”
They are, however, extremely useful. As Avi states, User Stories and their alternatives are an “ancillary practice that has helped many Scrum Teams over the years.”
Yet, the User Story format isn’t always the best Product Backlog Item (PBI) template to use.
Histoires d'utilisateurs
User Stories have their roots in software. Specifically, says Avi, the bad old days of programming. “I'm talking back seventies, eighties,” he explains, when “programs were really made for people who were as technologically savvy as the people who wrote them.” This was great for bragging rights for those who wrote code. But led to problematic program features that confused customers.
Additionally, Avi states, this approach failed in the core tenant of any business; delivering value for users or customers. “Programmers needed a way to talk about what they were making from the perspective of who they were making it for.” Hence the User Story format was born.
Though there are variants, the classic User Story formula is as follows:
As a <WHO> I want or need <WHAT> so that <WHY>.
Each bolded filled in to finish the template.
An example of a ‘who’ is the end-user. ‘What’ defines the requested capability and the ‘why’ is the desired result of using the ‘what’.
This simple formula with its focus on the end-user revolutionized programming and, like Scrum, spread well beyond software and I.T.
Strengths of User Stories
User Stories are built around empathy for the end-users. By starting with the end-user, the ‘who’ in mind, and building the ‘what’ and ‘why’ around that persona, User Stories keep the customer and how they will use the product or service front and center.
That is the strength of the User Story format.
It fosters understanding “from their perspective,” explains Avi, “what pain they're literally going through while using your product or service.” Whether it's an office chair you can't adjust properly or a design feature of a computer program that doesn't work, Avi stresses we have all felt the pain of a product or service that was designed without the end-user in mind. When it comes to delighting customers, “that kind of empathy is what we’re looking for. It is really powerful.”
Another strength of User Stories is at the epic level “because that's where your customer value is visible.” But by definition, there are many individual PBIs that make up an epic.
Weaknesses of User Stories
User Stories are, by far, the most popular template for Product Backlog Items. But are they always the best choice?
En toute honnêteté, la réponse est non.
As Avi points out even some of the earliest promoters of the User Story format have come to this conclusion. “If you go online and spend some time Googling around the people who created User Stories, a lot of these people are tremendous detractors of User Stories now. They think they've outlived their use.”
A major reason for this is the fact that end-user focused product and service design is now the norm. Or close to it.
Another, explains Avi, is the simple fact that there are a lot of PBI’s that can’t be easily focused or written with an end-user persona at their center. “In the field, I’ve noted many times where teams took longer to write the User Story format than to actually solve the problem.” Especially where the work to be done doesn’t focus on a human being.
Here, Avi gives two examples to make his point. One from software, one from hardware.
The software example is focused on dealing with an application programming interface or API, “Where one part of the program is getting data and API is collecting data from one part of the system and then sending it to another part of the system.” As Avi rightly points out, a User Story format here just sounds strange since it would amount to “as a system, I need data from place A sent to place B to resolve situation C.”
At times, User Stories can lose their effectiveness even when a human is directly involved. Take the act of a driver trying to stop their car. Yes, a human is applying pressure to the brake pedal with a desired outcome in mind, but that is really more of an epic than a single PBI since there are many parts of a system that need to interact in order to achieve that outcome.
If you’re working on a master cylinder, asks Avi, do you write the story with the disc break in mind? If every story in this scenario stars with the end-user pressing the brake pedal then “it doesn't actually get down to the details of what the engineers have to accomplish.”
Our next template is great for these kinds of PBIs.
System Stories
A System Story still contains the same features of a User Story. “Every backlog item has to have a value proposition, who it's for and things like testing constraints or what we would call Acceptance Criteria,” states Avi. The System Story just focuses more on a specific process.
Here’s the basic formula:
<Action verb> <Subject> So that <Who> gets <What> ou <Goal> is achieved.
The focus of a System Story is a particular action to be taken to achieve the desired effect.
Yes, the difference is nuanced but important.
Avi explains the difference by using this example from one of the consumer-packaged good companies he’s worked with.
“Let’s say, for example, you had a team making a beer. And they want to make a light beer. So they need to decrease the alcohol content or ABV.” A User Story for this scenario may state, 'As a light beer drinker, I would like a beer with lower alcohol by volume so that I consume fewer calories.'
“That’s great,” says Avi, “but it doesn’t explain what the workers in the brewery need to do.”
A System Story would get right to the point. “It's better to say, run the beer in tank three through the evaporator so that a lower ABV is achieved” (bold added to illustrate elements of the system story formula).
A simple, clear, and efficient way to make sure the steps of addressing a problem with a known solution are completed. That is the point of a System Story. We need this particular thing to be done.
Strengths of a System Story
Clarity and the recognition that sometimes systems are end-users themselves. And that not all-important work is done with a human in mind. System Stories are also perfect for work that needs to meet internal compliance issues.
Also, the format is much easier to write than the classic User Story.
Weaknesses of a System Story
The weakness here is the fact that System Stories may well dictate exactly what the team needs to do to accomplish a PBI. As Avi notes, this may decrease innovation. “there's always going to be that trade-off between constraints and innovation.
Loosen the constraints, increase innovation.” System Stories, Avi adds mean, “we're applying a little bit more constraint practice for that function.”
Job Story
This PBI template was born out of the work of Anthony Ulwick and his book Jobs To Be Done. These focus on motivation. Not on what an end-user wants but what they want to achieve. And they ‘hire’ tools to make that 
happen. “Nobody goes to the hardware store because they want a quarter-inch drill bit,” explains Avi, “they buy a quarter-inch drill bit because they need a quarter-inch hole.” Therefore, Job Stories focus on motivation over personas.
Their format is this:
Quand <Situation> I want to <Motivation> so that I can <Expected Outcome>.
The whole notion of a Job Story, says Avi, “is we're looking at what is the person trying to accomplish by employing our product.”
This focus is equally good for individual PBI, or epics of PBIs.
Strengths of a Job Story
Job Stories are great ways to create PBIs for products or services that are used by a wide variety of personas. Yet their focus on motivation and achieving an expected outcome keeps the end-user in mind. Job Stories are as flexible as User Stories in that they can be used for both individual PBIs and epics.
Weaknesses of a Job Story
The main weakness of a Job Story is the deemphasized persona. This is why Avi advises refocusing on personas when you get down to different use cases for your product or service.
“Take the concept of a power user of a program,” Avi says, “they’re a very different persona from a standard user. Power users are more demanding, want more features, and use a program in ways most of us never will.” The motivation of a power user he states, “is very different. So bring that persona back in at the right time to make sure you’re delivering value to them.”
What About No Template at All?
PBI templates can be powerful tools. But they are just that, a tool. And as with all tools, they should only be employed when their use is beneficial. In other words, their use is not required. If you and your team operate best with PBIs that conform to no template, don’t use them.
Avi stresses, however, that there are still five characteristics a well written PBI must have to convey all the context needed for the team to deliver an outcome aligned with the value in the requested work. 
- Value proposition
- Recipient of value
- Action needed
- Constraints
- Test Criteria
Don’t be afraid to mix and match the format of your PBIs. A Product Backlog can be comprised of User Stories, System Stories, Job Stories, and template free stories. When your goal is clear, pick the template that works the best for you and your team for each PBI.
Also don’t feel constrained by formats. Don’t tie you and your team in knots trying to write something in a way that doesn’t make sense. Pick the right tool for the job. Each job. Each time.
Watch the full conversation to learn more about each of these PBI templates and hear examples of their use.
This post is part of our ScrumCast series of conversations with thought leaders who have successfully helped transform organizations and empower teams and individuals. Each episode explores organizational Agility and Scrum patterns, tactics, and techniques that drive real-world success. Subscribe to our YouTube channel for the latest ScrumCast episodes.
French 
English 
Spanish