Great big enterprises often face problems when turning to agile: the executives still insist on substantial requirements documents, the coders prefer to build technical components that suit their expertise, and Dev Ops is a separate team happy to indulge in scripts and tools rather than consider customer experience. You have to ask, have user stories outlived their usefulness?
Over a chilled glass of Sauvignon at the agile blog-in the other night, a well-respected colleague of mine pronounced that he didn’t like the term “User Story”; he found it misleading when so many requirements of a complex system are not based on a user’s or even a customer’s interaction, and he feared that important features would be missed if one took the term “user” too literally. He suggested that it was good enough to say simply, “story” and dispense with the misunderstood user.
Many organizations have tried and been successful with agile in small pilot projects, but when they have attempted to apply that success to the organization as a whole they’ve make poor compromises to fit agility within their particular situation and ended up with agile in name only.
For example, a business might run a small team that’s able to realize agility by releasing finished, valuable software every two weeks. But then fail to reproduce the same small, cross-skilled teams when they scale because of an unwillingness to change reporting lines, refusal to dismantle departments and inability to tackle historic but wasteful processes.
An early warning that things may not be working out as intended may be found by inspecting how User Stories are written and split.
For example, you might find integration or testing stories; neither deliver independent value to the user by themselves, but creating stories like this does allow integration or testing teams to pretend they are working in an agile way. Crucially, the “user” part of User Story is an inconvenience if your goal is to create work for these specialist teams.
Removing the word “user” means requirements can be unlinked from creating end-to-end value and therefore allow siloed teams to operate with less need to collaborate with other teams and without understanding the value their part of the build will deliver to the overall solution.
To combat such a situation, a back to basics approach is required. Here are some pointers to remind us what user stories are all about and why we must always strive to keep the user part in mind.
- Write business stories that illustrate the business outcomes and value that will be created for the user (or customer) of the system you are building.
- Avoid technology related language (as far as is sensible) in your user stories (by all means add notes with tech stuff), but the user or customer should be able to understand the intentions and, vitally, value it will add when complete.
- User stories must deliver value so expect them to be a complete piece of work that delivers or retrieves real data to and/or from a user (or makes an improvement to such a scenario).
- Strive to make user stories that can be delivered into production independently and in the order the business decides.
- Resist splitting stories by technology or expertise – e.g. not testing, or integration stories. (these are not business requirements and doing so puts us at risk of dependence between stories) If you need to decompose stories to understand them better or for more accurate sizing, split user stories by business outcome and/or user groups so that each still delivers an increment of value instead of one part of a whole.
- If you are running Scrum, the development team may suggest bringing lower priority stories into the sprint to help balance work for the skills available in the team and keep everybody working, but do not create stories by technology or skill to enable this. (e.g. don’t allow stories to be split into coding and testing stories so the coders that are available can start a sprint or two early)
- To help the development team balance the available skills with the work being done, it is useful to have the backlog peppered with some small valuable fixes/changes that can be brought in when there is capacity for extra fillers but not enough capacity to “finish” something large. (These changes may or may not be user stories) It is not necessary that the backlog is exclusively made up of user stories – you can have fixes, updates and improvements, but do avoid using the word “story” as a generic term for all requirements; it’s confusing.
A User Story is a light-weight requirement from the user or customer’s perspective about their needs and the value they will get from it. A user story prompts a conversation and rapid, iterative development to meet the conversation’s conclusions. A user story cannot be built without close collaboration with the user and without the user understanding what the requirement will provide.
If any of those things are not present, do not simply drop “user” from the “user story”, you are probably hiding other problems while pretending all is well.