There’s one vitally important aspect of user stories in agile software development that very easily gets forgotten: collaboration.
The whole point of the lightweight, terse user story is to focus the whole team on collaborating throughout the development process with product owners and stakeholders, to understand the requirements and the best solutions to them. We don’t want the old approach: waiting for a nicely signed-off requirements document to be handed over and then implementing whatever it says. The problems with that are well known:
- Typically you’ve made one person - the business analyst or product owner - a single point of failure; they take the requirements from the stakeholders, and then hand them to the developers. We just hope they’re a genius who never makes a mistake!
- You’ve also put all the onus on the business stakeholders to know and understand what it is they really need, blind to any interesting technology options or constraints. By the time a developer sees the requirements they are “decided”
- In having that clear handover, you’ve given the stakeholders the sense that they’re no longer involved - they get back onto other projects and just wait for the release, the team never thinks to approach them (may not even know who they are)
You might write in the form of a user story (“As a… I need… So that…”) but if one person is writing your user stories, after talking to some stakeholders, and then handing them over to the developers to build, you’re basically doing old-fashioned requirements documentation with a different syntax.
This happened to us here, when we started off writing our user stories in JIRA. As a task-tracking tool it’s great, but as a place for collaboration with business stakeholders it’s rubbish; you have to get everyone who might be a stakeholder a license, and then persuade them to ignore all the technical aspects of JIRA and just focus on the comment thread, which isn’t a brilliant collaboration tool anyway.
So now we write our stories in Google Docs. Typically an epic within each document, because the reality is that most business stakeholders find it quite fragmentary to think of the requirements of a single story in isolation from the wider business goal. The whole team - developers, testers, product owner and business stakeholders - can contribute by commenting on the stories, or editing the text directly (Google Docs has a new “Edit as Suggestions” mode which is brilliant for spotting when someone has suggested a change and then accepting/rejecting it).
This process begins as soon as the story is drafted, and doesn’t end until the story has been fully developed, tested and deployed. And that helps with the mother of all issues in “building the right thing” - assumptions. Developers make assumptions when they have a requirements document that has been “thrown over the wall” to them. It feels like it is set in stone, so if it fails to answer a question then they just assume an answer. If the document is still alive, the stakeholders still available, it only takes a comment to get an answer.
The business analyst or product owner still has a critical role here, quite apart from producing the first draft. They need to keep the process flowing - make sure that stakeholders aren’t blocking developers by forgetting to reply to a question, make sure developers are asking questions in a way that makes sense to the stakeholder. But they become a facilitator of collaboration, not a single point of failure.
When the user story has been delivered, all the text in the Google Doc is deleted and replaced with the word “DONE”. Why? Well, Google Docs keeps a complete audit history so we can always go back and check the conversation and evolution of the requirements, but at the end of the day the product will continue to evolve long after we’ve stopped updating this user story doc. The last thing we want is someone finding the document in two years’ time and believing it is a description of how the software currently works.
The difference with this approach is almost magical; business stakeholders and engineers who have never collaborated before are now discussing issues in the same document, and I’ve seen good examples of surprising changes to requirements coming out mid-implementation (and being reacted to as a matter of course with none of the old “flippin’ users, always changing requirements!” grumbles). We’re still refining templates and there’s some thought needs to go into how to keep everyone proactively notified of changes, but the collaborative benefits of using Google Docs to evolve user stories far outweigh the challenges.
Comments