As  a developer/tester

I want to understand the user story

So I can build/test it correctly.

Mind you, this is a terrible user story. What does “understand” mean? And what is the acceptance criteria for “build it correctly”?

Life is messy, and the “As a…” template doesn’t always help. You can over-cram it to make it detailed, or over-abstract it, so the actual implementers won’t know what to do.

Have no fear. I’ll tell you how to concoct an effective user story.

It starts with…

1. Drop the template.  Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn’t fit. That’s ok. In that case…
2. Tell the story in a sentence. Maybe two. When people are presented with a new idea, don’t make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it’s a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to…
3. Anchor it. You know the “It’s like Uber, but for…?” pitch form every start up  is using? Everybody knows Uber, so they have something to reference the new information. In story-land it’s how the story fits into the application. “It’s like the log-in story from last week, but with extra validation”. Or, “Once we’ve done with the simple path, we can add more informed algorithms”. You’re showing where we were, where we’re going, and where this story fits. Then it gets interesting.
4. Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we’re able to connect our users based on their level of pet appreciation. There’s a reason we’re developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive…
5. Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it’s a also the setting for…
6. Give it context.Now that things begin to materialize, it’s time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end  calculation results. Context is awesome! We can use it to direct the team towards…
7. Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is…
8. Draw a line in the sand. Some things do not fall into our general rule.  VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we’ll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don’t like surprises.

Now, if you look at those steps, you’ll see shades of the template. It is simple (1), has motivation (2), sometimes has an example (6) . But in most scenarios, it is only the beginning. Most applications require more rich information to be developed.

You might be thinking right now – how do I write these things? Well, first, now you have a check list. Second, if you think that by writing this, people will suddenly understand your product genius, think again.

In the olden days of humanity, people didn’t write stories. They told them. They presented them. From all kinds of points of views and in different level of details. And they retold the stories in different ways. Until the cavemen understood how to catch the mighty mammoth. Then they told that story to their children.

Stories’ goal is to create a shared understanding in the team, to be the foundation upon which new features are built. They are a tool that can be used and abused. We just need to learn to use them effectively.

Which reminds me of another story, but that’s for another time.