Creating stories for the support team on an agile project

This article is one of a couple I am writing to explain how agile projects can hand over useful information to support teams if they want to. 

So this article is a (hopefully) straightforward description of how we can use stories to define the knowledge that to create and handover when the project goes live.

The first is to define who the “users” of the “knowledge about the project” will be once the project is completed. 

Many agile projects already break users into three groups:

1. Primary users are those people who will actually use the system for its intended purpose.
2. Support users (sometimes called secondary users) are those who might use the system, but only to support other users. For example a help desk, a production support team or an onsite technician.
3. Other stakeholders (sometimes called tertiary users) do not actually use the system. But they have a vested interest in it. In other words they will either be impacted by the system or be able to impact its success.

If you can identify the support users then you should be able to create a goal for each one. You might, for example define the goal as a “super story” of the format:

As the Java support team I want to support the xyx application so that the business can continue to use and enhance that system.

Or you might work the goal as a focussing question:

How can the Java support team support the xyz application for the finance division so that the finance division have cost effective way to manage the accounts payable process.

Once you know the goal of each support group (say training, production support, internal audit) then you can create a series of “user stories” for each of them.

This means creating a series of one line descriptions to explain what they want to be able to do, who actually wants to be able to do it and why they want to be able to do it::

As a production support team I want to monitor website usage so that I can report changes in usage to the e-business team.

As a production support team I want to be able to run audit reports so that I can detect fraud.

In some cases, stakeholders (as we as primary and supporting users) don’t want to do something, they want to know something. So simply capture their knowledge needs the same way:

As an internal fraud analyst I want to know if loans are made outside of standard criteria.

This should give you a list of potential “needs”.  And just as is done with normal stories you can prioritise them using “Moscow” and then elaborate them using acceptance tests or other approaches.

This should give you a reasonable idea of what the various different support teams will need after the project goes live. Now you just have to do something useful with that knowledge.