A short time ago I was talking to friends about teams who struggled to create “good” user stories. One friend talked about an organisation where most teams understood what a good user story looked like, but one or two still created user stories that looked like tasks from an old-style project. These might include things like “Design database schema” or “Review vendor proposals”. I’ve certainly come across that situation. I’ve also worked with teams where an early phase of the project is the GDS-style discovery or alpha phase, which predominantly involves research, prototyping, and exploration. These are not things that easily fit into the traditional “As a… I want… so that” format.
When I’m in these situations I often have to think back to the fundamentals. Why do typical user stories look like that? What is that trying to achieve? Once we strip away the tradition and the convention, for me it comes down to two basic things:
- Every user story must add some tangible value to your outcome. So we need to be able to complete a user story and then say, “Yes, even if nothing else gets delivered, this is a better product now that we’ve done this.” Reviewing vendor proposals doesn’t advance the outcome. Choosing which vendor to work with probably does.
- We want to start and finish several user stories each iteration, because we want to be continually advancing our outcome and continually have the chance to adjust our plan. This probably means none of our user stories should be more than a few days in duration.
Ultimately, that’s what this fancy agile thing is all about—delivering value incrementally. If we’re doing that in our own way then we’re probably on the path to doing this well.
That first bullet looks simple, but most traditional teams really struggle to split a big piece of work into small pieces where each piece produces incrementally more value. Vertical slicing an application is often the solution here, but if the project isn’t implementing software, or isn’t implementing it yet, then that won’t work.
When a team first tries to break down a big piece of work in this way I find they don’t succeed easily, and I often have to say “go back and try again” in various different ways. But teams do get better with practice.
One thing I might also add to the above list is this:
- The only person who can say it’s done is the product owner. If the PO can’t determine if it’s done to their satisfaction then it’s probably not a story that’s added real value.
And—at the start of a team’s journey—I would worry much less about some of the other things that people talk about, such as the “As a…” format.
In the end, behind the convention and well-used processes, there are some core intents which can still be achieved even if things are done in a slightly more relaxed manner.
niksilver.com 