Ventriloquists and puppeteers: unpicking user stories
I've been working on a backlog of user stories this past week. We put the initial list together a few months ago, to help us scope a new system. We're moving into delivery now, so I've been going through our stories and checking they still need to be on the list. I'm finding plenty of stories that need a touch more empathy.
In my younger days, I worked on big software projects for big companies. Things were different then. (You might remember, if you were around at the time.)
We specified IT systems as data and process. What information do we need to record? What are the rules for managing it?
Then we defined the features we would need to handle the information in line with the rules.
We used to start with data and process, then add users
If we had to store bank accounts, we needed to create, read, update, and delete bank accounts. Generally, that resulted in screens to create, read, update and delete bank accounts. That's how the system got specified.
We weren't total philistines. We cared about users, just like you. Once we decided there needed to be a 'create bank account' screen, we prototyped it to pieces. We aimed to make our systems as user-friendly as possible, given the limits of our toolkit.
What we didn't test for was whether anyone actually wanted a 'create bank account' screen. Why would we? Our users were bank clerks. Their job was to manage bank accounts. We worked hard to make their system pleasant and easy to use, but neither we nor they had any say in whether they used it.
Nowadays, we try to put users first
Twenty years later, IT systems aren't something you just use at work, because you have to. They've infiltrated every aspect of our lives. Some of them we have to use, but most of them are optional. Nobody has to use Dropbox or Instagram.
And the way we define IT systems has changed too. Keeping users happy has become more important, so we've started to specify software from the user's point of view. We work from people inwards, rather than data outwards. We write user stories.
"As a [type of user], I want [feature], so that [benefit to me]."
Instead of just listing a heap of screens to manage data, we figure out what the user wants to achieve. Then we build the tools they need.
But it's hard. We aren't our users. We're a business trying to make a living out of users. Our reasons for building software aren't usually the same reasons that people have for using it.
"As an Instagram user, I want an algorithmically sorted timeline, so that advertisers have to pay to get my attention,"
Said no one, ever.
The trouble with the user story format is that it can give you a fuzzy glow of empathy, when you aren't being empathetic at all. It's pretty obvious in my Instagram example that no user would ever endorse that story. But sometimes the issue is more subtle.
Ventriloquist stories put words into a user's mouth.
On the surface, a ventriloquist story looks reasonable. But the benefit doesn't ring true. Users don't want to sign up for newsletters so they can stay informed. They probably don't want to sign up for newsletters at all.
When I unpick these stories in my backlog, they aren't total nonsense. In the case of the newsletter signup, there is a real need from users to learn about our service. We know this, because they spend time ringing actual humans to get that information at the moment. But writing it as a story about a newsletter doesn't capture that need in a useful way.
Is it a user story or a business requirement?
Some of these stories aren't about the user at all. They're about the business. For instance: when you have to give up a load of information to get an insurance quote. Some of that information might be to give you a more personal quote, but mostly it's so they can sell you more insurance.
It's not only inaccurate to dress that information gathering up as a user story. It's risky. What if some smart designer realises it's not a 'real' user story and takes it out all together? Ooops. There goes your money making data.
Maybe these things belongs in a separate list of business requirements. But I prefer to rewrite these stories with the business as the user. It's easy for conventional requirements documents to lose their connection with business benefits. Keeping the story format means every reporting feature and admin screen has to justify its existence.
Puppeteer stories put requirements on other users
I've seen ventriloquist stories before. But puppeteer stories are new to me. One user's story is trying to control another user's behaviour.
"As user A, I would like user B to have some feature, so that user B will behave differently."
When I unpick puppeteer stories, there's often a heap of real user needs hidden inside. In the ones I've seen, user B is behaving in a slightly dysfunctional way - or at least, not in the way user A would like.
Sometimes that's because user B is having a hard time conforming to expectations. That's an opportunity to improve the user experience.
In other cases, user B's needs have changed. User A's expectations are out of date. That's an opportunity to change the experience, and maybe the business model.
User stories don't have to be right first time
None of our dodgy user stories caused lasting damage. They helped us create a clear enough picture of what we needed so we could find a partner to help us build it. If we'd spent ages grooming our backlog last year, we'd probably still be going though supplier selection.
Now we're getting on with building the system, we can take time to pick apart our wobblier stories. We can do more research and write better stories to reflect what our users need.
What traps catch you out with user stories? And how do you avoid them?