Definitions of Done should be a co-star — not a supporting actor

Something I realised recently (which I knew in theory but ignored in practice) is that reminding teams that they are the ones responsible for quality (through incrementally developing their Definition of Done) is crucial.

Entropy is inevitable. Technical debt will accumulate as time goes along. At some point, technical debt becomes so much that teams will want to add “technical stories” to sprints. People start arguing that senior engineers should have equal footing with Product Owners about what goes into the backlog. “We have so much technical debt — we need to treat it just like any other story and prioritise it into sprints!” the team would murmur. Before this post, I would almost always agree with the team.

We know that the Product Owner is responsible for optimising value (building the right thing) and the Development Team is responsible for quality (building the thing right). In ideal Scrum-land, the Product Owner puts the right things to build on the product backlog, and the Development Team specifies how to build the things right through a solid Definition of Done.

But I’ve rarely seen a Definition of Done that’s alive and kicking (usually it ends up in a dark and dusty corner of the team wiki). On the other hand, every single team I’ve worked in had a monstrosity of a product backlog. So why is it that backlogs commands centre stage while Definitions of Done slip into obsolescence? Perhaps it’s the topic of another blog post, but my…