In agile development the whole point of a story is … well, it’s a story.
It illustrates an instance. It illuminates an essence.
It tells a story.
There is a user. An actual person, who needs to get stuff done. A hero.
They probably need to get other stuff done too. This, whatever that is, is just one thing on their neverending to-do list.
Their reasons could be very simple or very complex.
I need to do this because my boss needs it by Tuesday.
Or
I need to to do this so I can get the documentation I need to go on holiday to Mauritius.
The point of expressing user needs as stories is:
- Stories are human, and so are we. We relate to stories because we are human and stories are how we are human.
- Stories can be simple, and conceal lots of complexity. “I booked a flight on my phone” is a simple story. Allowing a user to book a flight on their phone is complex. The complexity is our problem, not the user’s.
- Our job is to make it simple
Our stories, our main stories, don’t mention the databases we created, or the APIs we queried. We’re human, and that’s not important.
What’s important is the results we get.
I got that thing to my boss by Tuesday.
I booked that flight to Mauritius.
User stories should not specify every technical requirement needed to fulfil them.
That’s not the user’s job. That’s ours. We need to dig into the detail, users don’t. But those are just tasks. Nobody ever told their grandchildren about the user interfaces they interacted with.
They told them stories.
And the point of this story is … a story is the promise of a conversation. It’s where we set out from on a voyage of discovery. We know (roughly) where we want to get to. And we have an idea of how we might get there.
But we don’t know. We will have to learn as we go. The more we learn, the more we’ll know.
We need to talk more, not less.
I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.