The concept of a user story is not new, there are numerous training courses available, as well as supporting publications that inform us how to write that killer user story that is detailed enough to provide clarity and a value based function, yet simple enough to allow our development teams to estimate appropriately and reduce complexity.
However, even with these resources available at our disposal, some of the more frequent anti-patterns that occur in an agile project are related to the quality and simplicity of the user story. With reports suggesting that agile adoption is at ever increasing levels, why is the lifeblood of the ‘self-organising’ team restricted by poor user stories?
The lazy answer is that your story writers are too ‘Waterfall’ and base the story on a set of deep set requirements, ignoring the needs of the user and building too much complexity to build a Viable Product (see previous post on Quality for the reason for removing ‘minimal’). Though there maybe some truth in this, why as a collaborative team is this situation allowed to happen? If we are all in this together, then why not coach each other to achieve the objective?
Personally, I believe the reason is that there is often a loss of vision when preparing the backlog, splitting the ‘Epic’ into smaller story chunks; though designed to make estimation tasks easier can often lose sight of the user scenario that the Epic is designed to achieve. If we test stories in isolation of the Epic, yes they may achieve the acceptance criteria, but are they fit for purpose? In digital terms, does the journey improve the customer journey? Are our transactional workflows easy to follow?
It is this reason, among others that I believe halts progress and causes misinterpretation during a sprint, losing sight of the Epic objective, can lead to problems and conflict around achieving or setting the ‘Definition of Done’.
During UX walkthroughs of wireframes, keep the Epic objective in mind, see how a group of collective stories come together on the screen/wireframe to provide context on the user journey. adding these principles to story writing, acceptance tests and coding, should at the very least remove some of the misinterpretation to bring the cross functions together to achieve ‘Done’ and ultimately provide the user with a product that is user friendly and they receive a product that ‘Just works’