I’ve always thought you can tell when user stories are well written because anyone can tell roughly what the backlog of work is about. They’re written by or with the business in mind and focus on an outcome valuable to the business – maybe a new feature, an investigation into a problem or opportunity or a defect that needs fixing. Well-written stories make conversations easier and enable tasks such as prioritisation, refining, sizing, developing and testing to flow.
The funny thing is that the hard bit is often not writing the story, but figuring out what story is required in the first place.
As a Business Analyst, I’ve written many user stories. And I don’t like to begin any stories until I have a firm grasp of the expected outcome and value required by the business. I prefer to do my analysis off to the side, pulling in SME’s if required to help define the need and determine the scope.
I find it is too risky to add stories for which the rationale is not fully understood to the backlog. There are too many conversations, too many competing agendas and things changing too fast to risk miscommunication and the loss of value to the business through a badly written story or worse, the wrong story in the first place.
I became concerned at my current client site where anyone could add stories to the backlog. This often resulted in duplicate stories, large stories and stories that were difficult to understand. Some story titles didn’t make any sense at all, others requested the replacement of an entire system and many resembled fan fiction for Star Wars! The acceptance criteria often didn’t make things clearer, with most comprising nothing more than someone’s loose thoughts.
The result of this unrestricted adding to the backlog was waste – waste because meaningful conversations around prioritisation and implementation took longer and often had to be repeated. And, because conversations couldn’t keep up with the stories being added, the backlog became old. Many stories were over a year old and the product owners began to find it easier to review the latest story rather than the most urgent one. Who knew where that was?
I knew change to resuscitate our backlog was necessary because it was central to our team’s conversations and flow. However, well aware of the Agile adage of user stories as ‘reminders to have a conversation’ and not wanting to stop individuals from across the organisation from contributing stories, I needed a way to maintain engagement while not being seen as the ‘BA story writing absolutist’!
I introduced two new sections to our visual wall – ideas and pipeline. I encourage people to add their ideas to the ideas section. I interview the individual (consulting the Product Owner as I go) to make sure the real need and value is communicated.
On this basis – and drawing on their superhero powers – the product owners review the idea. Rejected ideas are discarded outright and ideas that are accepted move into the pipeline where I undertake more analysis. In this way, we ensure that the right story gets added to the backlog. And the story is written in a way that clearly communicates business value, making it easier to prioritise and refine.
I encourage every Agile team to review the quality of their backlog. If you find it difficult to make sense of stories, find yourselves arguing about what it is the business wants or come across duplicate or old stories, then consider being more disciplined about determining the rationale for stories before they actually become stories.
Our team do this by filtering stories through an initial ‘ideas’ stage. This provides a safe place to undertake analysis and to consider the value of each story. You will find that your backlog will support smoother interactions and conversations if it contains not only the right stories, but stories that are understandable and communicate business value.