Author: Lorraine Pauls Longhurst Published: LPLSC Blog Date: 22 July 2011

All functional and technical requirements can be written as user stories.  This will ensure everyone is speaking the same language!

Write User Stories for all Technical Requirements

At Agile Australia last week, Michael Rembach and I gave a presentation on the staged approach to introducing Agile used at Transport NSW.  At that presentation, I had a number of people approach me afterwards about the example I gave related to user stories.

I have outlined it below in more detail:

At Transport NSW, there was a technical requirement on our backlog called 'upgrade server'.  When the business was asked to prioritize this item, they thought of it as an IT responsibility and didn't understand why scalability was an issue they needed to be concerned with.

We re-worded the requirement as follows:

As a Bus Operator, I want to be able to access the on-line map within a few seconds even when there are ten bus operators using the system so that I can continue to use the system productively

By wording it in this way the business was able to do a few things.  They could identify who this was needed by - in this case the Bus Operators.  And they were fully aware that ten bus operators would be using the system within a couple of months.

The business could also clearly see the impact if this wasn't done i.e. that when ten operators came on board using the system - users would no longer be productive when using the system (because it would be too slow).  They quickly re-prioritized this item to the top of the list.

Also, by wording it as a user story, the development team was able to see who needed it and why which enabled them to be more creative in their solution.  Rather than upgrading the server, they determined that re-deploying the application server in a different way would solve this particular problem.

I believe that all functional and technical requirements should be written as user stories.  This will get you two large benefits:

1. It will ensure that everyone is speaking the same language - which gives the business more control cause they can better prioritize the backlog

2. It will ensure that developers understand why something is required which will enable them to be more creative with their solution