You can write the items of your backlog in several ways. One of the most popular is the User Story format.
User Story
To summarise, the User Story is a short format in which to write the necessary requirements to build a product. It must be understandable to clients and consumers.
It’s quite streamlined since we don’t want a requirements document to be sent via email to a builder team. In Agility, we want the best communication, enhanced collaboration, and truly multidisciplinary teams. This brings way better results than passing documentation around without any interaction between the people involved.
User Story format
The most popular format was: I, as a <User/Persona/Client>, want because <reasons/objectives>.
Example: I, as a visually impaired customer, want places I have to go to be accessible because this way I won’t have to go through embarrassingly asking people for help.
This isn’t the only format possible, but it has a couple of advantages. It answers three fundamental questions: Who? What? Why?
Here we’ll talk about a couple of common dysfunctions that may arise when people begin to adopt this rather enriching practice.
Diving headfirst into the solution
A common mistake when we’re new to agility. The user story above would be I, as a visually impaired customer, want direction boards to be written in Braille because this way I won’t have to go through embarrassingly asking people for help.
Notice how writing boards in Braille already ties the team to one solution. Everybody will imagine how to write Braille boards, and we’ve lost a rich discussion about other ways to solve the problem. Map boards that speak the name of a place on touch, tactile floor guide boards, redesigning rooms to make the environment itself easier to navigate, etc.
“Techish”
A slight variation on the previous one, this usually happens when the Product Owner comes from a technical area. It’s quite common for them to use part of their original area’s jargon.
Example: I, as a visually impaired customer, want a 200 cm movement sensor module installed along with an 80 Watt WRMS speaker because this way the name of the place will be spoken when I go through a door.
Now… Does the customer really want a 200 cm movement sensor module installed along with an 80 Watt WRMS speaker? No doubt it could be a solution, but it’s certainly not the only one. Depending on the jargon used, the conversation might even become impossible.
No conversation
Some teams forget that, in order for the User Story to work, it needs to follow the 3 Cs: card, conversation, and confirmation. Card is the story itself, presenting a problem my product’s consumer has. Without conversation, we can’t discuss what the possible solutions are. Besides, such stories are brief, and it’s almost impossible to build anything without discussing it between development and business.
No confirmation
The last C is the Confirmation that all people involved in the creation of the product understood the solution to be built. It’s good practice to write these confirmations down as acceptance criteria. There’s another very common format to acceptance criteria: “Since, when, then.
Example: Since the visually impaired customer has come to a map board when they pass by the movement sensor, then the map will say “You are at .”
Acceptance criteria do avoid unwelcome surprises by the end of the building. Imagine if we left a meeting without confirmation. We’d have some people picturing boards just written in Braille, people picturing maps with a “You are here!” button, etc.
Generic consumer
I, as a COMPANY, want… Now, wait a minute. The company is a lot of people. Who can we call in for feedback? Will anybody does, from CEO to interns?
I, as a CLIENT, want… Again. Does every client have the same needs? Can I call ask any of them for feedback at random?
When writing a story, be as specific as you can. Who’s the person who has the problem we’re trying to solve? They the one who has the problem we’re trying to solve. They’ll be the one we ask for feedback from.
Technical story
Be really, really careful with this. When we talk about deliveries in agile teams, we’re talking about multidisciplinary teams capable of delivering end to end. One slice at a time.
Creating a story for a technical task isn’t exactly good practice. For example, I, as a database administrator, want to create an index because this way queries will be answered faster. Is the index is created, but the queries remain slow, what do we do?
A better way would be: I, as a McGuffin consumer, want this XYZ Repost to be faster because I’m spending too much time on it to do my job. Notice how we can have several tasks within this story, including creating an index.
Technical stories end up leading the team to, instead of delivering a slice with value to the consumer, deliver just technical tasks that might just bring no value at all. Common examples are The Back-End Story, The Front-End Story, The UX Story, The Database Story, The Architecture Story, etc.
Always remember the full name of the story is USER Story. It must be about giving something of value to the consumer.
Spikes
We can ignore this rule when we need to study a technology that’s new to the team. In this case, we use the Spike. It looks like a story, but it doesn’t give value to the user. Its effort must be estimated, it must be visible on a task board, and it must have a deadline such as a Sprint.
Technical debt
Another reason to break the rules is when we do our good old shenanigans (technical solutions of dubious internal quality). Whoever looks from the outside sees a beautiful product, but has no idea it’s actually our friend Charlie Foxtrot holding everything together behind it. This creates technical debt. If we don’t pay at least part of it, it won’t be viable to enhance the product in its next iterations.
We can have Technical Debt payment. It works similarly to a Story or a Spike. The effort must be estimated, it must go to the task board, and it has a deadline.
The debt doesn’t come just from shenanigans. It might have been due to obsolescence or to the discovery of something new and better that might replace the current implementation.
A story without a purpose
Example: I, as a visually impaired customer, want places I have to go to be accessible.
If the story doesn’t have a reason, a motivation, I don’t know why I have to do it. Accessible how? In order to do or avoid what? What is the concrete problem we’re solving? In the example above, do I solve the problem with an access ramp? A tactile floor, maybe? I don’t know since the problem isn’t clear enough for us to slice it properly.
It’s actually common for stories without a true purpose to show up when someone from business or a manager has a pet feature. It’s something that won’t bring any returns, but they want it just because. This person will often use their higher position to ensure the story makes it to the task board.
The fact is that when it’s too hard to find the purpose of a story, it’s a strong sign that the story is unnecessary, and as such must be discarded, or at the very least moved to the bottom of the backlog.
Conclusion
Avoiding these dysfunctions isn’t easy, but we can do it with practice. Does any doubt remain? Do you think there’s a dysfunction missing somewhere? Tell us about it here in the comments.
And since you’ve made it this far, let me invite you to our Certified Scrum Product Owner (CSPO) training, where you can learn and practice how to create the best User Stories.
