Whenever I get into a gigantic blowup with my wife, chances are unmet expectations are at the root of the problem. One of us communicated a commitment (intentionally or otherwise) that did not get met. Which, of course, brings up all the other memories of unmet expectations, and before I know it we have spent so much emotional capital to figure out we didn’t make sure we saw eye to eye on what was expected. Whether it’s a team of two, or many more, this is usually the cause of any friction.
And yet, we still manage to go throughout our days at the office without any care of this principle. Let me explain with a recent example.
One of my colleagues recently asked me to help facilitate the planning session for his team’s very first sprint. His backlog was not only properly organized and prioritized, but had just about every asset imaginable attached to each user story. This sucker was ready for sizing. To get things started, I gave a brief overview of the goals of the session. If I’m going to ask them to properly define a goal of the sprint, I need to do the same for sprint planning. Before I did that, however, I asked a basic question: “How do you guys define done for a story?”
The silence was much longer than I had expected.
I look over at my buddy and say to him, “you’ve talked about this before, right?” After a quick nod in the affirmative, the rest of the team started chiming in. The discussion had occurred before sprint planning for sure, because I heard a lot of the familiar ways to define “done”. It just was not as clear in their heads as the PM’s.
Some thought that “done” meant the acceptance criteria had been met. Others thought the item needed to pass QA. Another mentioned the client needed to accept the work before something was “done”. That’s when the lack of clarity started to reign chaos into the meeting.
This is a huge issue in most companies today, whether they know it or now. For something so basic as defining when work is complete, it gets passed over most of the time as an assumption. Even if the assumption is made from the C-suite or higher, we know what happens with those leaps.
Most of my hurdles with teams defining done is clarifying the granularity of doneness. Some would prefer high-level definition as to allow more room for creativity. Others want very fine-tuned definition so they know exactly what is expected of them at all times. Side note: don’t assume which side your team falls on. Many creatives want boundaries, and developers freedom. What’s funny is when QA is the one pushing for larger granularity. It happens.
It’s also for all work disciplines to weigh in on this topic, not just leadership. Design, development, QA, product and senior-level management all have valid definitions. Therefore, the definition must include them all. Self-managing teams must give everyone the same voice, even if someone’s boss is in the room.
Please also don’t forget to document the definition and make sure it’s visible at all times. I usually like to stand right by the DOD and sprint goal during daily stand ups so that if there is ever any doubt of either, I can merely point. Nothing wrecks a sprint more than half-done work that was presumed to be finished.
There is so much more work on defining “done” in an organization needed, but it can’t happen until this first step takes place. If you know what is expected by you and your team every day, you can look at the smaller chunks of work more clearly and know when it’s time to move on. Please feel free to send some examples of how your team define’s doneness, the more the better!