Agile Perth Meetup - Writing User Stories

I went along to an Agile Perth meetup last night - Shelley Beeston from Thoughtworks presenting a session on user stories. I’m always enthusiastic about hearing concrete examples of different Agile techniques from the trenches on (presumably) successful projects.

Requirements approaches are something that I've experimented a fair bit with in the past, but I've always ended up fairly dissatisfied with each one. When it boils down to it, I consider some sort of functional description to be a critical element of the enduring system doco (along with commented source code & the 5-page ‘this is how it really works’ design document - see Alex Papadimoulis’s recent diatribe on this subject). There's too much lost context when you only have the source code to work off, particularly if there’s no-one around who was there as part of the original implementation. This typically leads me to err on the side of heavier requirements approaches & I often regress to use cases in the generally forlorn belief that they’re going to give me the document I’m after. In practice, they tend to be incomplete and out of date, and the ‘real’ requirements done informally in an even more ephemeral manifestation.

Shelley opened with a familiar description of the problems inherent in traditional hand-off based requirements management, before moving on to an outline of how she’s used user stories on projects for Thoughtworks. The interesting points I distilled were:

• She’s an enthusiastic supporter of the use of index cards for initial requirements discussions, even if they’re subsequently retyped into an electronic system. I’ve used cards for backlog management in the past, but I found the overhead of manually producing reports to take a lot of the joy out of it. This gives me an excuse to re-introduce the cards I still have sitting in my drawer.

• ‘Activities’ are documented separately to stories. If I’m interpreting/recalling this correctly, activities are high-level process interactions with the system, that may initially map one-to-one with stories & epics, but end up being one-to-many with the refined stories. The purpose seems to be a high-level roadmap of functionality that’s published to give the project team a locus for discussions of system progress/completeness.

• The analysts work on story splitting & refinement two iterations ahead of development. This is not too dissimilar to Dave Thomas’s recommendation of regular backlog maintenance, and would certainly ensure you’re kickstarting each iteration with ready-to-code stories, but systemic pipelining still makes me uneasy. It didn't help that Shelley uttered the classic phrase ‘mini-waterfalls’ in relation to the iterations. It’s possible, though, that projects of a certain size just don’t work attempting to do the full story lifecycle in a single iteration.

• Acceptance criteria. A structured mechanism for documenting the acceptance criteria for a story (that's not a cumbersome list of test cases) is one of the key components I think I've been missing from my approaches in the past. Shelley nominated the format:

  Scenario 1: Title Given [context] And [some more context]… When [event] Then [outcome] And [another outcome]…

  with the recommendation there be no more than about 4-5 scenarios per story. The scenarios are stored separately, in a Word document or spreadsheet.

I’m keen to put some of these ideas into practice — I suspect some combination of the activity documentation and acceptance criteria will satisfy my doco desires.