User Stories - creating and managing

User stories are a simple and speedy method of extracting what the business user wants from a solution. They are easy for anyone to read, having the following format;

As a (role), I want (feature), so that (benefit)

i.e. As a standard user, I want to be able to search for matters, so that I can easily select the correct matter from a list

With minimal training, this format will allow you to catalog a list of requirements for your new solution. Not only are you as a BA listing your requirements with minimal effort, but they are already in a format that is appropriate for all levels of the business to read and understand.

A colleague pointed out that user stories are extremely similar to standard user cases. This is true, with a few important differences.

1. A user story is a singular, independent unit of requirement - this allows it to be developed and tested according to it's priority in the backlog
2. User stories are written by the business users - this not only gets them to think about what they want, but also ensures that as a BA I'm not interpreting what they want into what I think they want.
3. User stories help create buy-in from users - By making the business users write their own user stories, you are encouraging the users to take ownership of their solution. If they can't see the benefit of it, then stop what you are doing right now, take a step back and look at the big picture

This is certainly not to say there is no place for use cases. They are still important and can be used within the development team as additional information.

You can also make user stories testable with scenarios.

Scenario 1: Scenario description
Given [situation]
And [another situation]…
When [event]
Then [outcome]
And [another outcome]…

So how do you know which user story to work with first? The proritisation should come from the project sponsor (with guidance if necessary).

An easy and visual method I'm experiementing with on one project is through Agile Zen, listing various stages including backlog, ready, completed and archive. The project team is able to log in and view the progress of the various requirements at any point.

So, you get the business user to write the user story, it's self documenting and it help creates buy in. What's not to like?

I spry with my nimble eye...

The apocryphal story is that in February 2001, 17 software developers met at a ski resort in Snowbird, Utah, to discuss lightweight development methods and went on to published the "Manifesto for Agile Software Development" to define the approach now known as agile software development.

Being a practising sceptic, I naturally didn't trust this version of events. My first thought is why they would talk shop at a ski resort of all places? You'd either be off piste or getting piste (said with a South African accent), or else being piste off that you are stuck with a bunch of blokes talking code when there are clearly better things to do.

That aside, one of the main benefits of using Agile are that you can realise business benefits quicker than with a traditional Waterfall approach.

This is due to the short iterations used in Agile, typically 1 - 4 weeks. If you have a project that can be made modular, where the business can realise some of the benefits after a short period of time, where the business and developers can work closely together, and the solution isn't mission critical, Agile should have a look in.

For instance, we have a project to overhaul our current manual method of closing matters. While the process can be quite extensive under certain circumstances, for 80% of matters, the process is straight forward. This will allow us to develop a solution that will deal with the majority of users. The remaining 20% will still benefit from the initial part of the process, and we'd look to deal with these matters as the next iteration begins, and so on and so on.

There are other immediate benefits of course; reducing the number of software bugs (through frequent testing) and increased team productivity (short iterations help provide the focus needed). Other benefits I can see happening is a greater buy-in from the process owner/champion and from the customer as well. Whether this happens or not I'll soon be finding out.

Now, where's my snowboard....

What's this all about then?

Like any good story, it's important to set out our main character.

This blog is all about a business analyst at a city law firm, documenting his foray into Agile methodology and development. Similarly to red riding hood, our protagonist will leave a trail of devasta...no, I mean a trail of lessons, snippets of learned wisdom, and more than likely, terrible jokes.

I can't promise any plot twists, but hopefully this will help any other budding Agilists (Agilae? A limber of Agiles?) out there.

I had warned you about the jokes.