I understand the Sprint Goal before Sprint Planning ends
I can state it in one sentence without looking at notes. If I can't, I ask before the meeting closes.
Printable DoD templates for different contexts, a feedback conversation framework with worked examples, and a contributing-well checklist.
A Definition of Done is written by the team for the team. These templates are starting points — adapt them to your context. A DoD that the team doesn't believe in is one they will quietly ignore under pressure. Start with fewer items that will always be enforced rather than many items that will be selectively skipped.
The most common failure mode is writing a DoD in a planning session and never referring to it again. These principles help build one that sticks.
A DoD imposed from outside is a standard the team didn't choose and won't defend. Write it in the first Retrospective of a new project or team — ideally by having everyone write three criteria independently, then comparing and agreeing on the five to seven that matter most. Shared ownership produces shared enforcement.
"Good quality" is not a DoD item. "No known bugs introduced" is. "Reviewed by another team member" is. "Well-written" is not. If the criterion requires the author's own judgment to verify, it is not a DoD item — it is an aspiration.
A DoD with three items, always enforced, is better than one with twelve items enforced selectively. Every time an exception is made — "just this once, we'll skip the review" — the DoD loses credibility. If a criterion cannot be enforced every Sprint, remove it.
The DoD should evolve as the team's standards improve. Adding a new criterion is always valid. Removing one should only happen if it was wrong from the start. The DoD standard should never move down. A team that removes items from its DoD under delivery pressure is not improving — it is rationalising shortcuts.
"If we shipped without this, would a user or reviewer notice something was wrong?" If yes, it belongs in the DoD. If no, it may be a nice-to-have standard rather than a done-means-done requirement. The DoD is not an aspirations list — it is a minimum bar below which nothing ships.
Most feedback that fails does so for one of three reasons: it describes the person rather than the behaviour, it is too general to act on, or it is delivered at the wrong moment. The framework below addresses all three.
Describe what you saw or heard — not your conclusion about what it means. "You don't care" is an interpretation. "You left before the stakeholder asked their question" is observable and can be discussed without defensiveness.
"Your stories are always vague" is a general verdict that creates defensiveness and gives nothing to act on. "The payment story had no acceptance criteria and the developer spent 90 minutes guessing the edge cases" is specific, recent, and directly actionable.
Feedback given within 24–48 hours is far more useful than feedback surfaced three weeks later in a Retrospective. Individual feedback belongs in a private conversation — never in a group setting unless it applies equally to everyone present.
When giving feedback that might be difficult to receive, this structure helps keep the conversation productive:
Observation
State what you saw or heard specifically. "In the last two Sprint Plannings, the stories arrived without acceptance criteria."
Impact
Explain what happened as a result. "The team spent the first 30 minutes of Planning writing criteria that should have been ready."
Question
Open the conversation — don't deliver a verdict. "What's making it hard to get criteria written before Planning?"
Request
State what would be different going forward. "Could we agree that stories need criteria before they enter Sprint Planning — and I'll flag it if I see ones that don't?"
Each example shows the same situation handled two ways: the version that tends to create defensiveness, and the version that tends to produce a useful conversation.
Too general ("always"), interpretive ("causes problems"), no specific instance, no path forward.
Specific instance, concrete impact, clear request, offer of help.
Blame-first, no curiosity about why it happened, no support offered.
No blame, genuine curiosity, focus on unblocking not on performance.
Sweeping, demoralising, no specific accountability, no proposed solution.
Specific actions named, direct accountability, invites explanation before proposing a fix.
Interpretive ("feel intimidated"), personal, no observable behaviour named.
Observable ("started to speak and stopped"), charitable ("don't think you intended it"), concrete proposed change.
Vague, no specific example, reads as an accusation directed at everyone and therefore at no one.
Specific incident, clear impact, question that invites solutions rather than assigning blame.
Before responding with defence or agreement, ask two questions: "Can you give me a specific example?" and "What would have been better?" These questions move the conversation from evaluation to learning. The first anchors the feedback in something concrete. The second gives you actionable information rather than just a verdict.
If the feedback is genuinely unclear or seems unfair, say so directly: "I want to understand this — can you help me see what I missed?" Not defensive, not dismissive — curious. Curiosity is the most productive response to feedback that lands badly.
These are the habits that make a team member genuinely valuable — not just technically capable. Print this, keep it visible, and review it at Retrospectives.
I can state it in one sentence without looking at notes. If I can't, I ask before the meeting closes.
I don't pull optimistic numbers to look good in Planning. I flag concerns about estimates before they become commitments.
Not halfway through. Before I start. If they're missing or unclear, I get them clarified before writing a line of code.
Not at the end of the day. Not at the next standup. The moment I realise I'm blocked. Every hour I wait is an hour the team can't help me.
I pull new work only when I have capacity to see it through to Done. Starting a new story while an existing one is in review is how everything ends up at 80%.
Spending two days on a problem alone when a colleague could have helped in 30 minutes is not independence — it is a Sprint risk nobody else knew about.
The board is the team's shared view of reality. If my story has moved to review, the board should show that immediately so nobody duplicates the work.
Every criterion, every time. I don't move a story to Done and then notice a DoD item hasn't been met. I check before I move.
If I notice a shortcut being taken that will cause problems, I say something when I notice it. The Retrospective is for patterns; in-the-moment concerns belong in the moment.
Not once. The first exception is the beginning of the DoD becoming optional.
Before identifying new improvements, confirm the one improvement we committed to last time either happened or didn't. Name it explicitly.
Five Retro actions with no owner and no follow-up are worse than one action that actually changes behaviour. I vote for the single most impactful change and hold myself to it.
Process feedback belongs in the Retro. Feedback about a specific person's behaviour belongs in a private conversation, not a group setting.
This is the clearest summary of what each side owns and owes the other. Print it and put it where the team can see it.
The Product Owner
The Developers
The PO and team disagree productively and regularly. The team pushes back on stories that aren't ready. The PO pushes back on estimates that seem inflated. Both sides trust that the other is working toward the same goal — delivering value to real users — rather than protecting their own turf. Conflict in Sprint Planning is healthy. Conflict in Sprint Review is too late.