User stories imageAgile
For a new project we’ve just started we have been exploring using a set of agile methodologies.  This is to see if we can find a more flexible method of building systems than our standard approach of trying to write a comprehensive set of user requirements, functional specifications and technical specifications to cover the whole of  a new system.  

From some of the projects that we’ve done in the past we’ve recognised that there can be a risk that requirements will change through the project.  You can end up building something that at the start of the project, seemed to be exactly what everyone wanted, but by the time the project is well-advanced, you have realised that requirements have moved on.  This either leads to projects delivering something that no one really wants, or ending up with massive scope-creep and you enter a never-ending battle to keep pace with an ever-growing list of new features.  Agile development seeks to find a way out of that maze.

SCRUM and User Stories
One example of an agile methodology is SCRUM, a technique seen in software development where development phases are referred to as sprints.  So a sprint is a development activity taking place over a relatively short period of time with well-defined and potentially quite narrow objectives.  One of the techniques often used to define the user requirements is something called ‘User Stories’

A User Story is essentially as statement along the lines of:

As a … (user)

I want to…  (something)

In order to … (benefit)

The process you follow is to get your user or users to write out a series of user stories that cover the new system that they want you to build.  These user stories can encompass a range of different requirements, functional or technical for example.   Once your users have written their user stories you then take them and group them together into similar features or functions.   You can choose whether you get users to prioritise them when they write the original user stories or you can do the prioritisation with the user representative once they are put together and sorted.  The idea is that at the end of the process you have a priority list that you can use to identify what development you should undertake as part of the first sprint.

Thoughts so far
It’s the first time we’ve tried this particular method and it takes a bit of getting used to.  Writing the right sort of user stories is not as straightforward as we’d expected.  They need to be really tightly focused on what users want to do with the system, not too aspirational, and there really needs to be a boundary or scope to what they are writing User Stories about.   It also seems quite easy to miss out features of the system that are going to be needed but haven’t been mentioned in the User Stories.  But we are learning more as we go along and realise that as we progress we will create new User Stories to fill the gaps.  That seems to be one of the key aspects of agile.

Advertisements