A healthy backlog means a healthy product
If you’re part of an agile team, you know what a backlog is. Even if you don’t, chances are you can make a pretty good guess. Just to make you good friends, let me introduce you.
Log, Backlog
The Backlog is your product, broken down into stories from the user’s perspective. It gives you, and anyone reading it, a clear view of what's going to be built.
Being able to invest little effort and get a product outline is what makes the backlog a valuable asset. After you understand the problem, you can write your backlog in a matter of days. Traditional documents can take weeks or months to get ready, and they do the same thing.
A good, prioritised backlog is the best solution to communicating a product vision. It’s the least effort for the greatest return. If you have ever struggled in deciding what to do next, maybe this is your answer.
From the user’s perspective
A backlog is a collection of user stories. They are fictional stories from the user’s perspective, telling what they want to achieve. It is made of three Ws: Who, What and Why.
A good user story might look like this:
John is an IBM employee and works at the Tutoia site, in São Paulo. He needs to request a new badge because his old one is not working anymore.
Let’s start dissecting it from the first W, Who:
John is an IBM employee and works at the Tutoia site, in São Paulo.
Anyone reading the story gets the context, who is trying to achieve something. The full Persona is somewhere else, but this alone has a lot of meaning. I bet you did picture John in your head, pretty accurately.
The next step is the second W, What:
He needs to request a new badge
The What, after the Why, helps us picture what John is trying to achieve. From here, we could say we have a good story and that it is understandable. But here’s the trick to get your story from good to perfect: Context.
The third W, Why, gives you context into what’s going on on the user’s mind:
because his old one is not working anymore.
The Why is important because it gives you the scenario, which changes everything. Let’s explore some alternate ones:
Because he forgot his at home
Because he needs to attend a client, and his badge stopped working
Because he’s a new hire and his temporary badge expired
See how much the Why can change your understanding of the story? The original one is pretty clear, it is just not working. John need to request a new badge and get a temporary one in the meanwhile.
The other cases might be a bit different. John might need a one-day badge, since his is at home. Or he might need to enter right away, since his badge stopped working but a client is waiting for him. Or even John is a new hire and needs to renew his temporary badge until the proper one arrives.
But wait, who’s the user?
Glad you asked. We've been talking about John, but who is he? Here’s where the Persona comes in. It is a fictional character, created to represent a group of users. It gets their personality, goals and frustrations.
If you have ever had endless discussions and couldn’t figure out where to go, the Persona might help. I can’t count how many times I’ve stopped a discussion and asked: But is this what John wants?
That question triggers something in our brains, and we empathise with the user. It helps shape the product to fit the user, not the client or the development team.
There are many ways to create a persona, and I’ll share mine with you. Keep in mind that the techniques here are like lego bricks. Whenever you find a new piece that suits you, fit it in. Remove anything that has no use.
First: Talk to people. You don’t need to be a Ph.D researcher to create a persona, but you need to empathise with your user. The value of going out there and talking to people is amazing. You get to understand who they are and what they need much better.
There are many proper ways to do this research, but for now you can rely on the basic questions: Who are you? How old are you? What do you do for a living? And then questions surrounding the problem you’re tackling. Note everything down, you’re going to need it later.
After you talk to some users — I usually go from 5 to 7 people — start with a fictional name and profile picture. They are important to help people picture the persona. You can get some from randomuser.me.
Now it’s time for a biography. I have both a short and long form, to help people revisit the persona. With the bio, write also an MBTI personality which will help you be in your user’s feet. UX Lady has an article on how to use MBTI to personas.
Now all you have to do is write goals and frustrations. Avoid narrowing them to fit the features you will develop on your product. Remember what you’ve heard in your research. What did they complained about? What did they wanted to do?
Create one persona for each user group you have. For example, if you target twitter users from tech companies, you might want two. One for the big tech company guy, other for the startup guy. Or maybe one for the executive, one for the developers. You get the idea.
You can download this persona template and start doing it right now.
Acceptance criteria
After you have Personas and a Backlog, you’re close to having the best backlog in town. The only thing missing now is a way to document what each story needs to do, objectively.
Our user story looks like this:
John is an IBM employee and works at the Tutoia site, in São Paulo. He needs to request a new badge because his old one is not working anymore.
The problem is easy to understand, but it doesn’t tell me how the user will do it. It is too broad, which leaves margin for interpretation. To make it more objective, let’s write down some acceptance criteria.
An acceptance criteria is a way to describe how the user will solve his problem. It helps tangibilize the story, doing the interpretation.
Let’s do it together for the story above. Some acceptance criteria might be:
Can I request a new badge?
Am I informed that may old badge will stop working?
Can I request a temporary badge while mine is being printed?
Can I check the status of my new badge?
When John can answer yes to all those question, the story is finished and the problem solved. The acceptance criteria is simple and grants a shared understanding of the solution. Anyone can see how the user’s problem is going to be solved.
What should we be working on next?
The backlog is an ordered list, where the most important stories are at the top. Important here means what will bring the most value to the user.
Prioritising the backlog is an exercise of product and marketing understanding. Get the client and the team together, and discuss what are the problems you want to solve first.
It may decide that three small stories are priority, because they are quick and bring a huge value to the user. Or you may find out that it is one big story, because that’s your main competitive advantage.
Either way, make sure you’re thinking about the user. If your backlog is ordered by the things that will bring more value to the user, you’re doing it right.
Is that it?
If you have good stories with acceptance criteria, and they are prioritised, that’s it! You are now a proud owner of a healthy backlog.
As business and market changes all the time, revisit the backlog to reprioritise it. Doing that from time to time is a good way to keep true to the user, you’re always delivering the most value.
All you need to do now is start working on the things at the top of your backlog. You already know what to do, go for it!
This article is part of a series that help you tear down the walls in your organisation. You can take a look at:
