The goal of this post is to highlight the importance of defining and being consistent about what done means at an engineering organization. Throughout my career I heard so many different versions of what "done" is. This is understandable when a team and an organization does not make it clear what it means to be done with a project. Here are a few examples of "dones" I have heard from my teams in the past:
"Done, I'm code complete! I just need to increase the test coverage a bit. I mean I need to actually write some tests but otherwise it is done"
"yep, we are all done, we even pushed the code to production. It is behind a feature flag atm but we will open it up after product team tests new features a bit more..."
"Done and done, we are good to start project Next! Documentation is the only thing but technical writers are going to finish that soon so customers know how use the new feature"
"Everything is done, we just need to migrate our customers. That can be started anytime though"
"Yep, all is done. Everyone is using the new messaging platform! The old messaging platform is still alerting us sometimes and it needs to be turned off but that is going to take some time..."
Rather than leaving it open to interpretation, a better way forward is for a team to agree on what done means. I understand that fully completing a project is hard work and is even harder when you are replacing an existing system/functionality with a new one. My point is this: none of the quotes above are referring to a fully completed project. A team needs to be told what boxes they need to check in order to call their projects "done".
Why make a big deal of defining what done means? Here are the 5 reasons why agreeing and being consistent on what done means matters to your team and your engineering organization.
Better Project Estimates:
A more complete definition of done will help your team members come up with more realistic and achievable timelines for getting a project done. It will force them to think through different expectations and possibly suggest trade-offs. Will this new feature be used by all customers on the platform? If not, can we only migrate the clients who will be using it?
More Sustainable Product:
There are always more things to do than we have time for. Our backlogs are packed with feature requests that needed to be done yesterday. Lack of a good definition of what done means makes it easy for our team to move on to the next product feature without fully completing the feature they are working on. Lack of documentation, incomplete migration, and not deprecating the old system fully will come back to haunt our team when we don't have a moment to spare. That is a recipe for disaster.
More Consistent Performance Reviews:
Better alignment on the definition of done allow the manager and the direct to look at a project outcome in a more consistent way. If your team member not only adheres to what your team considers done but also completes an extra feature it is easy for you, the manager, and the direct report to see that your direct exceeded expectations. Now think about a partially done project (according to your definition of done) with an extra feature in place. The second situation is much more likely to cause a disagreement due to lack of a consistent understanding about what done means.
More Consistent Promotion Calibrations:
Think about two engineering managers who are making a case to promote one of their team members in a meeting with other EMs and the head of engineering. Without an agreement on what done means each EM can call what their team member worked on done. This would not only be incorrect but a wildly inaccurate representation of how much effort each engineer put into making that project successful. Coding is important but it is only one part of making a project successful.
More Consistent and Clearer Communication:
Two of your team members are talking about an important project they are working on during lunch. One team member makes a comment that they will be done with the project later this week but what they really mean is that they are getting to the code complete stage. The team is still working on documentation, migration, and deprecation work. However, a sales engineer has already overheard the team member's comment. I will let you guess the rest. Agreeing on the definition of done will also help your organization communicate in a more consistent and clear way.
Definition Of Done Example:
- The code is complete with appropriate testing coverage.
- All users (or a required percentage of users) have migrated to using the new feature.
- The old feature is fully deprecated and no longer in use.
- All training and documentation materials are done and available to customers.
- The new feature is not causing unsustainable production issues (alerts, scale problems).
Be Flexible:
Your definition of done might not be on the list above. There might also be exceptions where your team member needs to make trade-offs and can't get all of the boxes checked. That said, defining and aligning on what done means will only enhance and bring more clarity to the conversations when those trade-offs need to made. You as a manager and your team members should be flexible but also aligned on when you call something "done".