The User Story has become a de-facto standard tool in Agile software tools, or what the Scrum Alliance calls a GASP – Generally Accepted Scrum Practice. The ‘Story’ originated in eXtreme Programming with the idea that a good way of describing what an application should do would be to tell stories about how and why its used. Then someone (Alistair Cockburn) had the idea of telling these stories from the users perspective, hence they are now known as ‘User Stories’.
But its important to understand the role of User Stories – and the fact that they are NOT an agile tool for specifying requirements or system functions. They are NOT, on their own, the way to capture requirements. The phrase ‘on their own’ is important here – User Stories are only a starting point for a conversation about and the design of a feature. Its not as if you can just hand a bunch of User Stories to a programmer and expect them to code it up.
Ron Jeffries uses the 3Cs to describe how User Stories are used:
- Card – the card the user story is written on – one or two sentences capturing the essence of the functionality the system should offer. The format used for this has become standardized over the years with many people using the form ‘As a <role> I want to <action> so that <result>’. Ideally, the User Story should present the user or role we’re talking about, the action or functionality they’ll invoke, and the benefit or result they want to achieve.
- Conversation – The User Story isn’t enough to specify the feature – it just kicks off the conversation between the technical and business folks where we explore the problem and possible solutions. This is where the simplicity and ambiguity of the User Story forces people with different perspectives to collaborate and to innovate. From this conversation, a clear, common understanding of what needs to be done should emerge – this is the point at which I urge teams to document, as lightweight UI wireframes, logic flow diagrams, decision rules, etc how the feature should work. Note that this documentation is happening AFTER the collaboration – it represents the output of the joint design of the solution and enables the learning from the conversation to be shared among a wider group of people – now and into the future.
- Confirmation – the third C is really the codification of the learning and joint design as a set of acceptance criteria – these effectively represent the requirements for the solution – if we develop functionality that satisfies these criteria then we have successfully implemented the feature. These criteria are usually the starting point for developing Acceptance Tests for the feature (that is not to say the testers only get involved in the User Story at this point – they should be involved in, or even leading, this whole process in going from Card to Conversation to Confirmation).
So its really the output of this process – the Acceptance Criteria, that represent the requirement specification, not the User Story that started the process off.
User Stories represent an example of the Lean principle of ‘Late Elaboration’ – but they also drive collaboration and innovation. They are also really useful for a Product Owner to engage a development team early, to build incremental requirements, to prioritize, defer and de-scope easily. I’ll address these aspects another time.
So how are User Stories abused? How about these gems I’ve come across:
- ‘As a developer I want to call the CFG_ADM API so that I can set/get compression configuration values’,
- ‘As a retail customer I want to click the ‘Add More’ button so my basket displays in a pop-up window’,
- ‘As a UI designer I want to check the order interface for CSS compliance so it works with supported browsers’
These are not stories about users, and the benefits they are looking for from the feature. They are technical tasks, or bits of specifications of how the system should do something (e.g. ‘pop-up’). They don’t describe things that could be easily prioritized by the Product Owner. But most importantly they are not an invitation to a conversation between technical and business people – they are the output of a design process, not an input.
Finally, while user stories are a useful tool in many situations, driving collaboration around business and customer valued features, they don’t every situation. There may still be a need for technical tasks on the Product Backlog, and some system functions may be invoked not by ‘flesh and blood’ users, by by system events, or external system calls. There is little point in using the User Story format for these – horses for courses!