Who's writing your user stories? Or, Agile under analysis.

The programming change from Waterfall to Agile methods was driven by the need to respond faster to client's needs in a digital age. The lack of speed was one of the biggest grumbles from clients as the market shifted before a project was complete. Speed of development was and still is crucial so anything that might streamline the development process was embraced. Now, enter Agile methodology with its sprints, scrums and user stories.

We've discussed the spin-off difficulties that Agile caused for project management because the iterative development cycle was difficult to cost upfront with a projection. This is because in Agile, small pieces of the whole are defined and developed and tested (usually meaning from a programming functionality perspective), shown to the client and approved, amended or thrown out. Some companies have got around this by reckoning from their experience on the usual number of sprints that a project undergoes and estimating a development cost based around this for the clients. There would be provisos that more would cost more and fewer would be less based again on the average cost of a sprint of work. So far so good.

But – isn't there always a but! The small pieces to work on in a sprint have been defined along user stories. This means defining that a typical user would want X and need to do Y to achieve Z (Andy touched on this in a recent post). The user stories are analysed and prioritised involving the client. Now here's the but. Do your user stories really work? Do they give good results when tested in situ with real users? How to write good user stories is generating lots of brain-cell energy. This is the big question.

Now programmers are not going to like the next bit. William Hudson, in his Nov/Dec 2013 article in ACM Interactions, User stories don't help users. Introducing Persona stories, (see also his draft fuller article) he queries whether allowing people not renowned for their interpersonal skills to define user roles is wise. He "found that technology-focused men working in IT had significantly reduced empathy". Don't shoot the messenger here!

Given that there are many people in the wider digital team who reckon that their specialism includes analysing user behaviour - digital architects, usability specialists, any human behaviour specialists such as HCI specialists, instructional designers, training analysts, marketing professionals, subject-matter experts and so on - then getting an acceptable definition of a user story might lead to inter-team debate. Do you suffer with this?

William Hudson makes some salient points. The usual way of defining user stories may miss out on how often the person needs to do this task and what variants might be needed under certain conditions. His fuller article gives a short overview of the history of user stories in Agile environments. The UK Government design brief for defining user stories uses the formula of actor, narrative, goal, for example. Where would this sit with William Hudson’s theory?

You may like the practical hints and tips given by Craig Strong in his blog What makes a Good User Story?, where a basic role definition for a user story is given but he does acknowledge that some stories might need more work.

This is a prickly problem – writing good user stories. Maybe a toolkit might help. See User Story Toolkit from Rally Software.

Anyone got any more tips?