Defining “done” in software projects

The definition of “Done” in software engineering teams can vary across different organizations. However, there are some common elements that typically define the concept of “Done” in software development.

Here are a few aspects commonly included in the definition:

1. Product Requirements: The software meets all the functional requirements specified that are in scope. It performs the intended tasks and functions as expected.
2. Testing: The software has undergone appropriate testing, including unit tests, integration tests, and any other relevant forms of testing. It meets your organization’s quality standards, and blocking bugs or issues have been resolved.
3. Code Review: The code has been reviewed by peers, and is known to adhere to coding standards. Code review feedback has been addressed appropriately.
4. Documentation: The software is accompanied by relevant documentation, including technical specs, API docs, run-books, release plans, etc.
5. Performance and Scalability: The software can handle the expected workload when released and allows for future scaling without significant performance degradation if usage increases.
6. Security: The software meets security standards, protects user data and is resistant to common vulnerabilities.
7. Deployment and Release Readiness: The software is ready for deployment to the production environment. It has been properly packaged, versioned, and documented for deployment. Any necessary configuration changes or data migrations have been performed.
8. Stakeholder Approval: The software has been reviewed by relevant stakeholders, such as product managers, business owners, or clients, who confirm that it meets their expectations.

No clear understanding of “done”

There are several signs that can indicate that your team is not aligned on what “done” means:

1. Inconsistent Interpretation: Some team members may think a task is complete when others believe there are additional steps remaining. Look for questions such as “should I just move my ticket to `done` before testing completes?”.
2. Scope Creep: The team regularly encounters scope creep, where additional work or features are added to a task or project after it was considered “done.”
3. Frequent Reopening of Completed Tasks: Tasks or issues that were previously marked as “done” are reopened because they were found to have unresolved issues or missing requirements.
4. Lack of Transparency: Team members are uncertain about what criteria need to be met for a task to be considered complete.
5. Incomplete Documentation or Testing: Documentation, tests, or other deliverables that should be part of the “done” criteria are often incomplete or missing.
6. Stakeholder Dissatisfaction: Stakeholders express dissatisfaction with the quality or completeness of deliverables. They may feel that the team’s definition of “done” does not align with their expectations or requirements.
7. Delayed Feedback and Review Cycles: Feedback and review cycles take longer than expected, with multiple iterations required before a task is considered complete.

If you observe any of these signs, it’s essential to address them promptly

1. Involve the entire team in crafting a clear definition.
2. Document this Definition.
3. Don’t be afraid to tweak the definition as your team and mode-of-operation changes.
4. Incorporate the definition in your “new engineering onboarding” document.

It might be tempting to solo-create this definition for your team, but consider the impact of top-down mandates, especially if you overlook important criteria. By collaborating, you create a more thorough understanding and get early buy-in, which builds ownership and accountability.

The Collaborative Process

1. Organize a Team Discussion: Bring together your team members in a dedicated workshop. Create an environment where everyone feels encouraged to contribute their insights and perspectives.
2. Brainstorm Criteria: Have an open dialogue to identify the key criteria that define completion. What deliverables, quality standards, and acceptance criteria should be considered?
3. Consider Different Perspectives: Embrace diverse viewpoints to capture a comprehensive understanding of “done.” Each team member brings unique expertise and insights that contribute to a well-rounded definition.
4. Define Clear Acceptance Criteria: Establish measurable indicators that validate completion for each task. For instance, consider functional requirements, performance benchmarks, usability assessments, and security measures.
5. Iterate and Reach Consensus: Keep discussing until the team reaches a consensus. Regularly revisit and update the definition based on project changes and feedback.

Implementation and Follow-Up

1. Communicate the Definition: Share the finalized definition of “done” with stakeholders. Ensure everyone involved understands the criteria for completion.
2. Accountability and Consistency: Build accountability with team members and trust-but-verify that everyone applies the definition consistently across tasks and projects.
3. Embrace Continuous Improvement: Establish a feedback loop to capture lessons learned and adapt the definition of “done” accordingly. Encourage regular reflection, identify areas for improvement, and share best practices within the team.

Realizing the Benefits

1. Enhanced Quality: By capturing a wider range of perspectives and expertise, we raise the bar for quality standards and minimize rework.
2. Improved Collaboration: Open dialogue and shared understanding foster effective communication, teamwork, and innovation.
3. Empowered and Engaged Team: Engaging team members in decision-making empowers them, boosts morale, and builds a culture of ownership and accountability.

Collaboratively defining “done” is a vital step towards unlocking project success in software engineering. By involving the entire team, we harness diverse perspectives, promote ownership, and align our efforts towards delivering high-quality outcomes. Embrace the collaborative process, iterate on the definition, and foster ongoing improvement to drive the success of your projects and the growth of your team.

The learning continues in…

• All chapters — The Engineering Manager’s Pocket Guide
• Chapter 5 — What Engineering Managers Can Do to Reduce Throw-Away Work
• Chapter 6 — Stakeholder Management For Engineering Leads
• Chapter 7 — One-way & Two-way Door Decisions
• Chapter 8 — From Busy to Productive: Time Management Tips for Engineering Managers
• Chapter 9 — Constructive Feedback Strategies Every Leader Should Know
• Chapter 10 — Leading vs. Managing in the Engineering World
• Chapter 11 — “Time to X” — metrics your team should track
• Chapter 12 — Defining “done” in software projects

If you have any thoughts or experiences to add, let me know! Respond to this post or let me know on LinkedIn. I’m happy to talk about anything software engineering related.