In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition . In both books I took on the topic of Backlog Grooming.
As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog
Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.
Backlogs & Refinement
Why don’t we first start with a definition of Product Backlog. From the July 2013 Scrum Guide, I’ve captured the following:
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The idea of sitting through a requirement workshop via teleconference seems like torture. Virtual requirements meetings tend to bottleneck our ability to effectively collaborate. Attendees and facilitators:
- dread the dead air and the anonymous beeps in and out: “Hello, this is Angela. Who joined?” “Bob. Bob? Bob, are you still on the call?”
- seem lost without visual cues like hand raising, eye rolling and head nodding. “Does everyone agree with that change? Is there anything else we need to add?” Silence. Facilitator wonders: “Does that mean everyone agrees or no one is paying attention or everyone is talking on mute?”
- feel constrained when they can only collect/offer information verbally, one person at a time.
- feel limited when their most successful in-person techniques don’t translate to a virtual environment.
Painful, but Required!
Despite the dread and pain, the need for effective virtual collaboration is increasing. Even in small to mid-sized organizations, it’s rare to find all stakeholders sitting in the same building or even in the same city.
“Some of these things, are just like the others, some of these things are not quite the same, can you guess which things…” Analysis is the “anti-methodology”, always seeking coherence, relationship and significance rather than exclusion.
Let’s use some BABOK categories to organize stakeholder “stated requirements”. In the process we will see how we can distinguish “requirements” from requirements when we model potential solutions.
Let’s say your stakeholders have stated things like: