AAA Toolbox: As a... I want to... So that...

26 Feb 2012

Esse é um post de uma série que eu compartilhei internamente na ThoughtWorks uns anos atrás. Eu escrevi em inglês, então republico assim, mas se a série acabar sendo bem popular, eu prometo traduzir tudo.

Stories can be tricky things to write. You have to make them small enough, but also sensible enough to get some business value out of them. Most importantly, they need to be easy to recall at a glance after an initial conversation about them has been had.

There are a few questions that people normally ask before doing anything:

• What am I doing?
• Why am I doing it?
• Who am I doing it for?

When using user stories, it is advisable to specify what needs to be done in a way that does not force developers to implement a sub-optimal solution just because a specific one is written in a card. In the other hand, developers working on larger stories can, over time, loose sight of the purpose of a story and implement something that doesn't fulfil the underlying goal of a story or ignores the needs of the target audience. Probably the best place to keep that information in order to avoid loosing sight of those key questions of a user story, is in the story card itself!

Years ago, a company called Connextra was using a standard template that addresses just that. Mike Cohn mentioned it in his book, and it became the de facto standard for writing user stories. Here's how Mike puts it:

As a (role) I want (function) so that (business value)

For example:

As a business traveller, I want to book a mid-size car in Newark Airport for tomorrow so that I can be sure a car will be available for me on arrival

This model forces the writer to think about the audience of a given functionality and the value it should fulfil. This way it is easier to maintain the focus on the most important questions and make the conversation revolve around it. Developers will have greater insight on what is important once they know the business value the story aims to provide; Quality Analysts can consider the skills set of the audience and how well rounded a story needs to be; Business Analysts may challenge the product owner when he or she prioritises stories whose business value is not aligned with projects objectives; and so on. In the example above, "business traveller" indicates a user that does this operation frequently, while the business value highlights the importance of the reservation being a guarantee of service, implying that the booking transaction must be committed as part of this story. Note that the story defines values for all major attributes of the reservation. Additional stories would be required to allow the user to change the parameters, check availability and process payment.

Story writers have to keep in mind that, even though this format helps at least putting some thought to the interested parties and business goals of a given story, it is not replacement for conversation and any template is only as good as he information you fill it with. The most important thing will always be discussing the story with other team members. Frequently, these discussions can reveal gaps in understanding or in the story itself and it is important that this feedback makes its way into the story.

I just had to use this image from Rachel Davies. I hope it is Creative Commons.