I’m sorry but I need to vent. I’ve been encountering these patterns a bit too often lately and I just need to get these thoughts off my chest.
The patterns are these:
- Organizations and teams consider it the Product
Owners role/job to write every aspect (word) of every User Story. And,
if the stories aren’t “complete enough” the team kicks it back to the Product
Owner to do a better job.
- User Stories are too robust. I’m being kind here. The Product Owner / Analyst writing the story writes a complete requirement (pages, all information) before ever showing it to the team.
From my perspective, these are both agile requirement anti-patterns, you shouldn’t be doing it this way, and I’ll try to explain why. In both cases, I think it goes against some of the very core principles of the agile methods. It’s not changing your Waterfall views and while, you’re saying you’re agile on the outside, on the inside you’re still handling your requirements the same old way.
- User Stories are intentionally incomplete;
- User Stories are a promise to have a conversation;
- User Stories are defined (refined) iteratively around those conversations;
- User Stories are LEAN; just enough and just in time definition;
- Eventually, a User Story is refined enough to be ready to enter a Sprint; the team usually determines this.
These are generally agreed principles for the purpose of User Stories. Nowhere does it imply that you go off and write a treatise that explains every nook and cranny of each requirement and then pass it to the team. Where’s the discussion, the collaboration or the joint understanding of the problem you’re trying to solve?
Read my lips: don’t overly develop
your stories; become more comfortable with ambiguity
Product Ownership Basics
Yes, the Product Owner “owns” their Backlog. But that doesn’t imply they have to write every word on every User Story. I like the view or attitude that the entire team (development team, Scrum Master, and Product Owner) “owns” their backlog. Sure the Product Owner is the final arbiter, but everyone contributes. For example, developers should be writing technically focused stories. Testers should be adding testing stories and refining acceptance criteria. The Scrum Master should be facilitating grooming sessions where the entire team discusses (estimates, risk, design, dependencies, etc.) for each story.
In fact, I think the entire team has a responsibility to visit the backlog each day. And not just view it and send an email to the Product Owner, but team interaction around the backlog. Last time I checked, the team was self-directed and accountable for their success.
Read my lips: It takes a Village to
“own” a backlog
Instead of looking at your User Stories as traditional requirement artifacts, please consider them a “conversation starter”. I have a personal heuristic that I want User Stories to only enter a sprint 70% complete. They should exit the sprint signed off and 100% complete. The point is, allow ambiguity to be explored within your sprints, you’ll develop way better solutions to your customers’ challenges that way.
And don’t force your Product Owner to write everything. What kind of an agile team is that? It takes a Village to initiate and maintain the Product Backlog. Yes, the Product Owner is the mayor. But the entire Village needs to engage in the day-to-day operation of the town. Make the care and feeding of your backlog a continuous and shared responsibility.
Stay agile my friends!