Pet Peeves: Getting Agile Requirements ‘Right’

Pet Peeves: Getting Agile Requirements ‘Right’

You are currently viewing Pet Peeves: Getting Agile Requirements ‘Right’

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

The patterns are these:

  1. 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.
  2. User Stories are too robust. I’m being kind
    here. The Product Owner / Analyst writing the story writes a complete
    (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
  • 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

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!


Leave a Reply