User stories are an excellent way for business teams to tell development teams what features/functions are needed because they cut straight to the chase.
Let’s say I want the team developing my new blogging app to provide me with a Preview button.
I could write this:
“The system as designed must provide the ability for blog writers to instantly preview posts by pressing a ‘Preview’ button.”
Not bad, I suppose. But the language is passive, and has a tendency to make one a bit… yawn… sleepy. Further, once it’s lumped in as sub-bullet 3.5.1.3 alongside my other, similar, 10-pt Arial sub-bulleted requirements on page umpteen of a dense (albeit beautifully and painstakingly crafted… wait–is that gold leaf embossing on the title page???) requirements document, there’s a chance it may be missed. Lastly, there is no indication what benefit this this functionality will provide (although, we can probably guess). In short, there is a risk I won’t get what I want because the team doesn’t see what I want or doesn’t fully understand.
Now, what if I were to change it up a bit; what if I were to say it like this, instead:
“As a blog writer, I want to instantly preview my post by pressing a ‘Preview’ button so that I can see what my post will look like from the reader’s perspective before I publish it.”
By using the format…
“As a <type of user>, I want <some goal> so that <some reason>”
…I have come right to the point, explaining what I want clearly and simply. In addition, the language is active, putting the developer in my shoes. I have communicated three things:
- What feature to build <some goal>;
- The context it will be used in <type of user>;
- Its relevance <some reason>.
What if I were to simplify things even further by writing my statement on a card or a Post-It note that the development team could stick on a wall, along with other user stories so they could get stand back to get a look at the big picture? This would save time and effort because my focus would be on documenting what I want rather than documenting what I want. It would also make it easier for my dev team to understand what I want in the context of everything else I’ve asked for because it would be a statement on a card on a wall that the team could move around and group with other, similar user stories when deciding what to work on next.
That’s agile in’it?
Find more tips like this one at Professional Services Plus
