Let me tell you a story
As we have been getting to grips with Agile ways of working we have been evolving the way we communicate within the team, the way we approach planning and refinement as well as the ceremonies. One of the most important things that we have found is the need to ensure our user stories are focussed on valuable end user outcomes.
We use the ‘As A, When, Then’ method which is a pretty standard way of articulating stories, but fully understanding what the value of the stories are has been the real challenge. Almost anyone can write a story which outlines the needs for a particular function, but are they able to write stories outlining how the end user, the most important person, really benefits from the creation of said function? This is the challenge that we have been stepping up to, and continue to learn and work on.
During the refinement of stories and acceptance criteria, we are starting to really dig deep into the user stories and asking ‘why are we doing this’. If the stories do not have a real end user benefit, why are we doing it? Ultimately we should be working on tasks that have a real benefit to our users, rather than something that we think should be done because we a) already do it, b) think it sounds like a good idea, or c) because we can. It is this mindset to writing stories that will help everyone, from Dev to Stakeholder, really understand how we are making a worthwhile product for the people that keep the business a success.
This is an ever-evolving process and it is great to have an open minded team to bounce the stories off for clarity, or to challenge the reasons for having them in the first place.
There is also the minefield of Business Requirements vs End User Requirements which can greatly assist in confusing the user stories. But that is a whole other story to tell…