User Stories — a surprisingly handy conflict navigation tool
Probably everyone heard about the User Story. But how many people here have actually read Mike Cohn’s “User Stories Applied“? Not so many hads in the air I see… It might be one of the most misunderstood agile practices, so let’s begin by saying what exactly is this thing.
What is a User Story?
You might recall a famous conversation between Ken Schwaber and a CFO on a plane:
CFO: What do you do?
Ken: I help people build software in 30 days.
CFO: You mean I don’t have to wait 15 months to get what I don’t want?
Ken: That’s correct. I’ll give you something you don’t want in 30 days.
This simple conversation shows that we, as IT professionals should not be about what our customers want, but what our customers need. We are designing the solution, but the customers have needs. Stories are perfect for getting the WHY out of your client. Without the Why, we don’t know how important is the thing we are building or if it matters at all. Great thing to use, you’re minimizing waste and making customers happy.
But don’t ram it everywhere. Remember that for a user story to make sense you need a PERSON. It should be renamed as HUMAN STORIES, so that monsters like this wouldn’t be conceived: “As a system I need an interface to be able to test myself”. This is an overkill. Why on earth would you waste your precious time to do something so pontless. Don’t put stories everywhere, admit that you will have bugs to solve that sound ridiculous in the story form, or regression tests, or internal enhancements or large refactoring sessions… Let them be what they are.
So once we understand what a story is, and get the crucial fact that we need an actual person to construct a story, let’s look at it from a different perspective.
A Different Kind Of Story
It’s a tool that helps us understand what the other side needs. So what if we use it inside of a team? Let me show you a couple of situations.
One: A team of five fantastically intelligent, testosterone-pumped guys fighting each other on a daily basis: “Beacuse you didn’t do this”, “You know s**t”, “It’ s your fault” and stuff like this.
Two: A sunsetting product, a team of 6, a Scrum Master who is in fact a micromanager and an ever-pessimistic Product Owner. A new Scrum Master comes in and sees something like a landscape after the zombie apocalypse. No one knows what to do, barely moving group of undead haunts the room.
One solution was applied to both cases. Both teams were gathered in a room, explained what a user story is and how to use it, given index cards and pens and told to write a card to everyone. In case number one I was tearing apart every violent card that appeared and in number two I spent almost an hour guarding the door before everyone wrote a meaningful card. In both cases we walked out with a poster of rules to be followed, all explained why and quite easy to maintain.
How to use them?
So how to use a story this way? First, you have to identify roles and names in the team. For example if we have a team of six:
- Mark, Systems Administrator
- Tom, Software Architect
- Jill and Jay, Programmers
- Sahid, Translator and Documentation Expert
- Loev, Test Automation Engineer
We construct the story as:
As a <role>/<person> I need <role>/<person> to <action> so that/because <the WHY>
We can write a user story as a role or as a person to a role or to a person. For example:
As a Test Automation Engineer, I need Programmers to include me in the process of planning, so that I can start working on my test cases right away.
As Mark I need Tom to inform me about major system updates so that I can make sure that the hardware is compatible.
After writing those we display them on the wall, affinity group them talk anout them and reformulate them into a set of rules.
Same rule applies if you have two fighting individuals. They have to write non-violent cards to each other. Worked really well with my dad and my teenage brother fighting over a vacation getaway.
Why it works?
- Beacuse the person writing the card isn’t midlessly throwing unrealistic expectations and accusations.
- Beacuse the person writing the card needs to realize the exact position he or she is in as the requestor.
- Beacuse putting something on paper calms emotions and makes people think about what appears under their pen.
Try it and let me know how is it working for you.
Originally published at www.xsolvesoftware.com on March 12, 2015.