Definition of Ready Retrospective

Check your stories are ready before the sprint starts.

Try this retrospective live

Our Current DoR

What does our Definition of Ready look like today?

We say a story is ready when it has acceptance criteria, but I don't think everyone agrees on what 'good' acceptance criteria looks like.
Our DoR includes: user story written, acceptance criteria defined, story pointed, and dependencies identified.
Honestly, I'm not sure we have a formal DoR. We just pull whatever is at the top of the backlog.
When It Works

What goes well when stories meet our Definition of Ready?

When stories are properly sized and have clear acceptance criteria, sprint planning is so much faster. We're done in under an hour.
I notice we have far fewer mid-sprint blockers when dependencies are called out upfront during refinement.
The team feels more confident committing to stories when we've all had a chance to ask questions before the sprint starts.
When It Breaks Down

What problems arise when stories aren't truly ready?

We pulled in a story last sprint that had no acceptance criteria and it ballooned into a three-day back-and-forth with the PO.
Stories without clear scope tend to get 'done' differently by different developers, and then QA finds inconsistencies.
We keep discovering dependencies mid-sprint that block us for days. This should be caught in refinement.
Improve Our DoR

What changes should we make to strengthen our Definition of Ready?

We should add a checklist to our Jira ticket template so nothing gets missed before a story is marked ready.
I'd like us to agree that no story can enter a sprint without at least one refinement session where the whole team was present.
We need a clear rule: if a story doesn't have acceptance criteria 48 hours before planning, it doesn't get planned.

What is a Definition of Ready Retrospective?

A sprint goes better when the work in it was ready before planning started. A Definition of Ready (DoR) is your team's list of entry criteria a backlog item has to meet before it's pulled into a sprint, such as acceptance criteria, an estimate and known dependencies. The Definition of Ready Retrospective checks whether that list is doing its job. The board has four columns. Our Current DoR sets out what the criteria actually are today, which often turns out to differ from person to person. When It Works collects examples of ready stories going smoothly. When It Breaks Down covers what happened when unready work got into a sprint. Improve Our DoR is where you agree on changes. Use it when planning keeps running long, stories keep stalling mid-sprint, or nobody has looked at your DoR in months. It works for Scrum and Kanban teams alike. In TeamRetro people can add ideas anonymously, so problems with refinement come out even when they're awkward to raise.

Definition of Ready Retrospective format

Our Current DoR

What does our Definition of Ready look like today?

Ask everyone to write down what they think the current criteria are. Many teams have an informal or unwritten DoR, and the differences between people's answers tell you where to start.

When It Works

What goes well when stories meet our Definition of Ready?

Look for specific sprints or stories where being ready made a difference, like a short planning session or a story finished without chasing anyone. These examples show the team why the DoR is worth keeping up.

When It Breaks Down

What problems arise when stories aren't truly ready?

This column usually says the most. Ask for specific stories that entered a sprint without meeting the DoR and what happened next. Look for patterns: do the same gaps keep coming back, or hit the same kinds of stories?

Improve Our DoR

What changes should we make to strengthen our Definition of Ready?

Agree on concrete changes, such as adding or removing criteria, changing how refinement works or adjusting your tooling. Aim to leave with 1–3 changes to trial next sprint.

When to use this retrospective

  • Your team keeps hitting mid-sprint blockers, scope creep or stories that can't be finished in the sprint, which often means work wasn't ready when it was planned.
  • Sprint planning runs long or feels chaotic because the backlog wasn't refined before the team commits.
  • You're onboarding new team members and want to write down what 'ready' means for your team.
  • Your team has a Definition of Ready but hasn't reviewed it in a while, and it may not match how you work now.
  • After a hard sprint where unclear requirements or missing information caused delays or rework.

Suggested icebreaker questions

  • If your backlog were a kitchen, would it be a well-stocked, organized pantry or a chaotic fridge full of mystery leftovers, and why?
  • What's one thing you wish you knew at the start of a task that you always seem to find out halfway through?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Share your current DoR before the session so people arrive with real examples.
  • Talk about process gaps, not individual mistakes, so people can describe what went wrong without blame.
  • Timebox each column. DoR discussions easily turn into refining individual stories, so keep the retro on the criteria themselves.
  • Agree on 1–3 changes per session. A DoR that tries to cover everything gets too long to follow.
  • Involve the whole team, not only the Scrum Master or Product Owner. Developers, QA and designers each feel unready stories in different ways.
  • Check at the next retrospective whether the changes made planning and delivery easier.

Frequently asked questions

What is a Definition of Ready retrospective?
It's a retrospective that reviews your team's entry criteria for backlog items. The board covers your current DoR, what works when stories meet it, what breaks down when they don't, and what to change.
What is the difference between Definition of Ready and Definition of Done?
The Definition of Ready sets the entry criteria a backlog item must meet before it goes into a sprint. The Definition of Done sets the exit criteria for when work is complete. This retrospective looks at the first.
How often should a team run a Definition of Ready retrospective?
Run it after a hard sprint with unclear requirements, when new people join, or every few months to check your DoR still matches how the team works.
Is the Definition of Ready part of Scrum?
No. The Scrum Guide defines a Definition of Done but not a Definition of Ready, which many Scrum teams add for themselves. Keep it light so it doesn't become a gate that blocks useful work.
How long does a Definition of Ready retrospective take?
About 45 to 60 minutes for most teams. Keep the discussion on the criteria themselves, or it turns into a refinement session.

Related templates

WWE Smackdown Showdown Retrospective

Tag-team your sprint review with a wrestling theme.

Working, Not Working Retrospective

Sort what's working from what isn't, then fix it.

Quarterly Retrospective

Step back from the sprints and review the whole quarter.

Baby Steps Retrospective

Pick one small change your team will actually finish.

Ready to run this retrospective?Try this retrospective live