So last night, I had the opportunity to see Ken Schwaber in action at the AgileNYC event in LimeWire’s Tribeca offices with a friend of mine. It was a great event with a lot of people ranging widely in their exposure to Scrum. I find that there’s always a particular nuance that I relearn when I attend these talks, and the key one that stuck was all about how to plan and execute towards the goal of “Done Done”. Read on to find out more!
For those of you who could use a refresher, “Done Done” is based on knowing that a work item is capable of passing a set of agreed-to criteria between the stakeholders as well being capable of launching the very same work item into production. It was refreshing to hear a reference to the basic project management tenet, the Iron Triangle, and the concept of altering schedules/time (e.g. the Sprint length) to improve quality. Essentially, the common issue occurs when one person’s definition of done often doesn’t match someone else’s definition of done. When you can check off Done Done with everyone, that’s when you know you’re golden!
So at the end of the talk, I went up to Ken and asked: “What if you have the Product Owner/Manager constantly changing their requirements and definition-of-done-s on you in a start-up kind of environment?” To paraphrase, his response was clear and simple: it is what it is. The fault lies in both camps: on the team’s side, the PO isn’t being responsible by sticking to a clear-enough definition of done, and the team/ScrumMaster isn’t demanding a clear-enough definition in the first place. Both sides need to work something out, or else something or someone will break.
At the end of the day, you need to have clear requirements/user stories that also have clear (and preferably specific!) definitions of done (think acceptance criteria, functional/integration/unit tests, documentation, qualifying against industry standards, etc.). It also helps to have an overarching Sprint objective and Sprint-oriented definition of done. It’s the only way to get good expectation management and ultimately, good software. So slow down, talk it out, and get then it done!