User stories for production support (part 1: FAB)

User stories are a great way to focus your requirements around the real needs of your users:

As a user I want to report on the number of users who read articles on my blog so I can see whether a topic is popular or not.

This approach can work really well for a production support team, but sometimes the users are listing issues or bugs, which don’t naturally follow the format. For example:

• The current report is two slow, it needs to run in less than 30 seconds
• Can I have the date modified to use Sydney time in Australia rather than GMT
• The report sometimes crashes when I run it

In practice, I often find people present their “story” or request as an impact statement:

• The issue;
• Why it is significant; and
• What I want to see happen.

This works OK but is quite informal, so I found a good way to capture the same infomration is through the “FAB” structure that salespeople sometimes use.

FAB means “Feature, attributes and benefits”. So instead of listing the features of your product, you focus on how the particular attributes of your product provide a benefit to the customer.

Of course, the customers of a production support team rarely feel the need to sell the benefits of their requests, they just want everything urgently for free.

So here is how I like to use the FAB structure to capture their requirements:

Impact statement

• The feature (or thing with an issue) is ___________________
• The attributes are _________________
• The impact that is it having on me/us is _______________

For example …. The usage report (feature) takes up to 4 minutes to run (the attributes of the report that I won’t to talk about) and the impact is that it really annoys the users. Other attributes might be the fact that it crashes once a day or the fact that the time zone is based on GMT.

Then I then agree or capture the desired outcome:

• The feature (which is often the same but might be a new report) is _____________
• The desired attributes are _______________
• The benefit of changing these is that _________________

For example, I might capture the “story” for my report as

The report (feature) needs to run in under 30 seconds (the attribute) so that we can run it on the fly during presentations (the benefit)

If you look at it, this is almost identical to the standard wording for a story. I just find the impact statement a little more instinctive for users raising requests that might be bugs, changes to performance or other non-functional requirements.

I also like the fact that I can now list all the “stories” that relate to a feature rather than a thing the user wants to do. So for a small enhancement I might list a number of desired attributes for the one feature.

You can track the user requests in this format or you can use this format as an “epic”. In which case you would then break it down into stories for the purpose of getting the work done.