When a developer says they are done, what does that mean? I’ve worked on many different client projects and it’s been slightly different every time. Developers are often left to take responsibility on ensuring a task is complete, however many times they are left with subjective, nuanced and changing job descriptions based on the whims of project managers or the business. A good Definition of Done not only brings value by ensuring completeness of work, but it also shields the developer from the random, tedious requests. Here’s a few principles on creating your team’s definition of done.
- Write it down, communicate it out and revisit it every sprint. Do not assume the team members know and understand what it means to complete a task.
- Use it during estimations and sprint planning as a baseline for what needs to be done for each task, but don’t get too rigid with it. It’s a guideline, not a mandate.
- Don’t try and get too enterprisy with it. While a similar pattern or template could be used across teams, make it unique for the technical team with the details needed to make the process easy and complete. Need to update the user docs? Put a link directly to the document in the checklist. Again, make the right thing to do the easiest thing to do.
- Peer review the work and create an incentive for the team members who have the most reviews per month. It doesn’t have to be big, but giving out a $25 gift card to Chili’s or buying them a funny tech t-shirt can do a long way to encouraging the behavior.
- Good task flow is a balance between executing on parallel work streams and not wasting people’s time. Key checkpoints can save the developer time and effort.
Now that we have a good baseline on how to use a DOD, let’s take a look at a basic example. This is the template I take to most projects as a starting point and adjust according to the particular companies details.
- Working Code – This should go without saying, but delivering quality code satisfying the tasks or issues is the highest priority.
- Unit Tests – Good unit tests covering the core functionality or bug fix goes a long way not only for the current effort, but for use throughout the life of the code base.
- Integration Tests – Does the code changes have any effects on external interfaces or data integration? If so, a decent set of integration tests to cover the functionality goes a long way.
- Automated Regression Tests – update or add new automated regression tests to cover the functionality. These should be plugged into the existing automated regression set and should serve as the baseline of how developers prove their code works and meets the requirements of the task.
- Checkpoint 1: Peer Review – At this point, the developer has completed the code, written the tests and tested the change in the larger context by running the accepted regression suite. Prior to contact with the business, the changes should be reviewed and accepted by a peer or the team as a whole. This peer review should be handled in less than 10 minutes but goes a long way to ensure people’s work is holding to team standards and expectations.
- Checkpoint 2: Business Review – After the peer review is complete, the business owner should be notified and provided with the documentation to justify why the task should be considered complete. Getting a signoff from a user prior to deployment to downstream systems (QA, UAT, etc) saves huge amounts of time related to feedback loops. This business review should be a final checkpoint, not the only checkpoint. The technical resource should be communicating with the user as much as needed throughout the development process, whether it be UI design, data validation requirements, or other questions.
- Updating Technical Documentation – take 15 minutes and update the docs. In the team’s DOD, you could even have a list of the docs to be updated. ERD, process diagram, screen validation documentation, etc.
- Updating User Documentation – take 15 minutes and update the docs. In the team’s DOD, you could even have a list of the docs to be updated. If the UI changed, update the screenshots and provide the new instructions.
- Update Task – Once all is completed, the final step is updating the task. Again, it doesn’t take long (15 minutes) to write a good explanation of what was done, what was touched, what tests were written or changed, signoff info and getting the documentation updated. At this point, the task’s actuals should be updated to show the time spent and document any anomalies. Use this time to also push anomalies to the project manager to be reviewed and possibly get them addressed, if they might become longer term issues.
Some developers and team members may look at this list and see nothing but busy work. While it can sometimes seem tedious and boring, following these processes actual protect the development team from volatile business expectations and gives a kind of social contract allowing the developers to properly cover all needed aspects of delivery. It’s also a great tool to have in hand during sprint planning or general task estimations – a small change in code may take 2 hours, but updating the documentation, writing tests and updating the users to impact changes may double that time to 4 hours. Having the DOD helps everyone baseline their tasks and estimate their throughout more accurately.