"Done": A Dangerous Word?
In Software Engineering, the word "done" might seem simple, almost obvious. In reality, it can be deceptively slippery. What’s "done" for a developer implementing a feature may not be the same as what’s "done" for QA, Product Manager, or from a delivery perspective.
Misalignment around this single word can lead to wasted effort, unexpected bugs, a false sense of progress, or even customer frustration. As Ana Filipa Silva puts it, one of the Engineering Manager’s key responsibilities is to help teams define, communicate, and agree on what "done" truly means, so everyone moves forward with a shared understanding.
Why Definition Alignment Matters
When a team isn’t aligned on the definition of "done", subtle but impactful issues start to appear. A feature may reach production without full test coverage, documentation may be incomplete, edge cases might go unnoticed, and technical debt can quietly accumulate. From a delivery perspective, this misalignment can lead to planning the next work under the assumption that a story is finished, while the team is still fixing gaps.
That’s why having a shared understanding is so important. A definition of this word might look like bureaucracy at first glance, but it’s not. It’s about predictability, trust, and quality.
When every team member understands what is required for work to be considered complete, teams reduce rework, build confidence in their deliveries, and free up mental space for creative problem-solving instead of constant firefighting.
The Many Faces of "Done"
"Done" doesn’t mean the same thing to everyone, and that’s not a problem by itself. Problems arise when these different perspectives are never made explicit.
The Role of the Engineering Manager
For Ana Filipa Silva, as an EM, defining "done" is about clarity and alignment across the team and its stakeholders. It’s not something Engineering Managers set for the team. Instead, the team should guide this definition, and EMs should help to make it explicit, visible, realistic, and sustainable.
A big part of the manager’s role is creating the conditions for good conversations to happen. That starts with psychological safety, allowing everyone to share concerns and thoughts, ask questions, and be transparent. Individually, people often already have an implicit sense of what "done" means. But when that understanding isn’t shared, misalignment emerges. To our EMs, it’s important to bring these assumptions to the table, encouraging discussion, and helping the team agree on a definition that reflects both quality expectations and delivery realities.
Predictability is another key concern. Planning only works when "done" is understood in the same way by everyone involved. Rather than pushing for speed, Ana prefers commitments based on a realistic view of the work, including testing, documentation, validation, and anything else required to feel confident in the outcome. When "done" is clear, planning becomes easier, less stressful, and more trustworthy.
More than just planning, this definition can also help navigate trade-offs. There are moments when teams need to make conscious decisions about scope, risk, or timing. The EM’s role isn’t to override technical judgment, but to challenge, help frame those decisions, make constraints visible, and ensure that any compromises are intentional and understood by the whole team.
Finally, what "done" really means should never be set in stone. Teams evolve, systems grow, and priorities change. What was "good enough" six months ago may no longer be sufficient. Revisiting the definition doesn’t need to be a formal scheduled moment, but it should happen whenever the existing definition starts losing relevance.
When this works well, "done" becomes a shared reference point that supports autonomy, quality, and confidence across the team.
The Role of Developers and QA Teams
"Done" isn’t just about making the code compile or work on one developer’s machine, it’s far more complex than that. While getting a feature to function is an important first step, it’s only the beginning.
A solution might seem to be working and still contain breaking edge cases, performance regressions, missing functionality, or small issues that will only be noticed later in the existing codebase. It may also introduce code that is hard to understand, extend, or maintain, slowly becoming a liability. If "done" is defined only by validating the happy path and confirming that "it works", critical aspects of quality are overlooked. Sooner or later, the system pays the price for those mistakes.
From a developer’s perspective, as explained by Sérgio Gomes, Senior Software Engineer, "done" starts with meeting the acceptance criteria, but it certainly does not end there. Delivering a feature also implies that we meet our engineering standards. That includes:
- Clean, readable, and maintainable code
- Tests that cover both happy paths and edge cases
- Team review and agreement on the chosen solution
- Compliance with approved designs and consistency with the design system
- Meeting observability requirements
- Deployment readiness, such as feature flags when needed and the ability to roll back safely
For example, implementing a feature isn’t just about writing a component that works:
export const BetsTable = ({ bets }) => (
<table>
<tbody>
{bets.map((bet) => (
<tr key={bet.id}>
<td>{bet.team}</td>
<td>{bet.amount}</td>
</tr>
))}
</tbody>
</table>
);
A feature like this may technically satisfy the acceptance criteria, but is it "done"?
From a developer’s perspective, "done" might also require:
- Compliance with approved designs
- Handling of edge cases and non-happy path states, like error handling, empty data
- Accessibility and semantic correctness
- Consistency and usage of a design system
export const BetsTable = ({ bets, loading, error }) => {
if (loading) return <div role="status">Loading bets...</div>;
if (error) return <div role="alert">Error loading bets: {error}</div>;
if (!bets || bets.length === 0) return <div>No bets available.</div>;
return (
<TableWrapper
data={bets}
columns={[
{ header: "Team", accessorKey: "team" },
{ header: "Amount", accessorKey: "amount" },
]}
/>
);
};
Another important factor in defining "done" is the collaboration with our QAs. They ensure that the feature meets the predefined requirements, while validating that the whole system functions the same way as it did before. The QA team brings a different perspective, challenging and exploring the feature beyond the happy path, asking and raising scenarios that developers might fail to notice. In fact, looking back, "done" work starts before the coding and testing processes. As a team, it’s crucial during refinement to ask about all possible outcomes of a given task. This way we can minimize unexpected scenarios and prevent bugs from appearing later in the process.
Ultimately, Developers, QA, and Product each have their own perspective on what completion means. When "done" is not clearly defined, this often leads to misalignment and unnecessary rework. That is why it is essential for everyone involved to agree on a shared level of confidence, one that clearly outlines the requirements and expectations needed for a feature to behave as intended, while addressing the quality standards that matter to all roles.
"Done" Belongs to Everyone
One of the easiest ways for a definition of "done" to fail is when it quietly becomes the responsibility of a single role. Sometimes it’s assumed to belong to Engineering Managers, Product Owners, Developers, or QAs. In practice, as in other aspects of the Software Development Lifecycle, such as Quality, the definition of "done" only works when it’s treated as a shared responsibility across the team.
Through the Eyes of the Engineering Manager
From an Engineering Manager’s perspective, shared ownership of "done" is less about control and more about creating the right conditions.
That means encouraging early conversations about quality and risk during refinement and not just at the end of a story. It means making space for concerns to be raised without fear of being seen as blockers. And it means supporting teams in holding themselves accountable to the standards they agreed upon.
Ultimately, when "done" belongs to everyone, the EM’s role shifts from enforcing a process to reinforcing a culture of responsibility, trust, and continuous improvement.
Through the Eyes of the Developer
From a Developer’s perspective, "done" is certainly not a personal milestone, it’s quite the opposite, a shared responsibility. This means involving everyone from the beginning of the definition so that the team can reach a shared level of confidence that the right conditions are met for a feature to be considered truly "done".
In summary, it's about collaborating early, asking the right questions, think of all possibilities, anticipate edge cases and aligning expectations across everyone involved. This way, we can ensure that we are able to deliver a feature with quality and stability.
"Done" is a Commitment, not Just a Checkbox
At its core, "done" is not a status update or a column in the Jira workflow. It’s a commitment the team makes to itself and to everyone who depends on its work. A commitment that the problem was understood, the solution was thoughtfully built, the risks were considered, the quality was evaluated, and the result can be trusted.
For Engineering Managers, that commitment shows up as predictability, clarity, and trust in planning. For Developers and QAs, it shows up as confidence in the code, in the system, and in the decisions made along the way.
When "done" is treated as a checkbox, responsibility becomes fragmented. Work moves forward, but questions remain unanswered. Edge cases surface late and quality becomes negotiable. From a developer’s perspective, this often means revisiting code that was considered finished. From a manager’s perspective, it leads to missed expectations and unreliable plans.
But when "done" is treated as a shared commitment, something shifts. Conversations become more honest, trade-offs become explicit, and confidence in what is delivered grows naturally. All of these without the need for extra controls or last-minute validations.
Reaching this point doesn’t require perfect processes or rigid definitions. It requires alignment, openness, and the willingness to revisit assumptions as teams and systems evolve. Most importantly, it requires recognizing that "done" is not owned by a single role, but rather by the collective.
In the end, a strong definition of "done" reflects more than how a team works. It reflects what a team values: trust over shortcuts, clarity over assumptions, and responsibility over speed. When teams share that mindset, "done" stops being a risky word and becomes a reliable promise.
Ana Filipa Silva, Sérgio Gomes, Ana Carvalho
