What’s the Story?

Requirements are about one thing and one thing only – the Story.

If you can tell the story, the team will understand what you are asking for and know why they need to build it.

Everything else between Epics, Features, User Storys, Product Backlog Items, Tickets, Issues, Work Items (the list goes on and on and on) – is fitting your story into units for work to be done.

But getting that story right takes practice.

When building requirements there are a few things you need to keep in mind.

Who are you writing this for?

If you don’t know who your audience is, how will the team building the solution, and even worst, how will you know if you are building the right solution? Scifi writers write science fiction novels, they don’t write Murder Mysteries (unless it’s a Scifi Murder Mystery). They know their audience and they know who they are writing to so that they can sell their books but also so the reader can enjoy them.

Why are you writing this?

We often forget to ask this question when building out requirements simply because we assume – “well someone must have asked this before it got to me” – but maybe they didn’t in which case it’s your job to ask why you’re building this. And if you can’t figure it out, that’s your first hint as to whether you should be working on this. Once you know why you are writing it, you will be able to see the value and the reasons for why you are writing it which will make your job that much simpler to undertake.

When are you building this?

The Story structure

Stories have a beginning (the introduction), a middle (the meat, where all the action happens, where the goodies in the story come out), and an end (what happens, what’s left when everything is said and done). Find any book from ages 0 to 99 and they are all the same – beginning, middle, end. Where stories resonate with people is in the spaces between those sections, how they string them together, how they flow from one section to another.

If you’re starting to write requirements for the first time and don’t know where to start, forget the tools, forget the structure and focus on these three elements. It might not be perfect, you might not have “edge cases” or “acceptance criteria” (which are valuable) but what you will have is a description of what you are doing, why you are doing it and who it’s for.

And that’s the best requirement to start with.