We’ve all been there. We’ve had multiple conversations with a team about an upcoming milestone where they excitedly tell you they are tracking to be done on time.
Then it’s milestone day. You download the build, or settle into the presentation and shortly thereafter you begin to feel uneasy. Unease morphs into worry, which quickly becomes frustration. This milestone isn’t done at all. It’s missing key elements of what you expected.
Turns out “done” is tricky business. It’s easy to have divergent opinions on what done means, even within a small closely knit team.
An example
CEO says: “We need a build with the new social feature integrated.”
Engineering hears: We need to to make sure the backend technology works.
Product hears: We’ll need to user test.
Marketing hears: We’ll get a build we can use to start making visual collateral.
Design hears: We need pixel perfect designs.
Business Development hears: I can start pre-selling this feature.
Without context on why this build is needed and what is most important about it, each team member will assume that the goal aligns with what he or she thinks about most.
This is why it is so important to create a shared definition of done at the onset of the project, and to truly understand what work goes into getting there.
Let’s ask our fictional CEO why this build is important and what she wants to see.
“I believe our once-a-day users will become 3 or 4 times a day users once we add this new social feature, which will dramatically improve new user acquisition. We expect this feature to fundamentally change our CAC and retention. We need to get it right before we roll it out to the whole user base. We need a build with this feature working that we can user test and begin iteration on so we can ship it to full user base as planned early next year.”
With this information, engineering knows a working tech build isn’t going to be enough and business development and marketing know we’re not ready for this to be externally facing yet. Product knows to prepare a user testing plan and design knows that iteration will be required.
Because the team knows what to build, and why that's important, they will be much more aligned on what a complete milestone needs to include. Without that context, they'll have different ideas of what done is, and are much more likely to figure that out when it's time to deliver.
Taking time upfront to get specific on what done really means is critical for a team to deliver. It’s more work upfront, but it means the team is positioned to finish the right work faster.
On every project I’ved worked on - whether I started at the beginning or joined part-way through - I made sure we had a document that clearly articulated the definition of done. This clarified what work needed to be done, why it was important, what finished looked like and who needed to see it. Without fail, this document created alignment, set expectations and improved speed to market.
Take a look at your critical initiatives have and make sure that there is clear alignment on what done really means. There is no time like the present to course correct if required.