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 organisations have tried and been successful with agile in small pilot projects, but when they have attempted to apply that success to the organisation as a whole they’ve make poor compromises to fit agility with their particular situation, and ended up with agile in name only.
For example a business might run a small team that’s able to realise 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 upmost in our minds.
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.