Early in your Scrum education you learned about the importance of the Definition of Done (DOD). It’s the description of your engineering practices that a Scrum team needs to hold itself accountable to when they work toward building a potentially shipable increment of software by the end of their sprint.
At some point not to far down the road in your Scrum education you likely learned about the importance of a Definition of Ready (DOR). The description of the steps that a team needs to complete on Product Backlog items before they’re viable candidates for Sprint Planning. In the case of User Stories, the DoR might be:
- Written in the 3-part format (as a … I want … so that …).
- Has acceptance criteria that is understood and agreed to by the Product Owner and the Development Team.
- Has been sized by the Development Team.
By the way, if these steps aren’t completed for the Product Backlog items at the top of the Product Backlog before Sprint Planning, you can expect Sprint Planning to be a bit of a train wreck. For a tip on the topic, read the Scrum Guide. More specifically, read the “Product Backlog” section under “Scrum Artifacts.” Here you will get the details on Product Backlog Grooming. Something a lot of teams misunderstand.
But I digress.
So what’s a DOI? It’s a Definition of Impediment (DOI). Way too often I find that Scrum Teams don’t have a common understanding of what an impediment is. Without that common understanding, team members aren’t likely to be able to tell if they are experiencing one, much less state it to their teammates.
How does this situation pan out in real life? Picture a Scrum Team that holds their Daily Scrums and always answers the third question with “no impediments.” Team members will even do this after clearly using “impediment language” in answering the second question in their Daily Scrum. For example:
Today I will be working on TASK X, if I can get PERSON Y to return my calls. No impediments.
Today I will still be trying to figure out TASK Y. No impediments.
Today I will be working on TASK Z with my old laptop because the new one isn’t fully configured. No impediments.
Sure they’re generic examples, but I see real world variations of them all the time. I believe some of this behavior potentially comes from Development Team members incorrectly equating “having an impediment” as “being incompetent”. I can’t admit I’m having trouble so I simply declare myself impediment free to boost my IQ. Too often, however, I think a lack of impediments being stated in a Daily Scrum stems from a poor understanding of what an impediment looks like.
Scrum Masters take notice. If you feel the Scrum Team your on suffers from this type of behavior, engage the team in a discussion on their Definition of Impediment. You’ll likely uncover a gap that’s actually holding the team back from implementing an effective impediment removal process.
Give it try. Bring up DoI at your next retrospective and let me know what you uncover.
Thanks for reading.
Comments are closed.