DoR and DoD for systems analyst interviews
Contents:
Why interviewers ask about DoR and DoD
When a hiring manager at Stripe, Linear, or Notion drops "walk me through your team's Definition of Ready" into a systems analyst loop, they are not testing your Scrum vocabulary. They are testing whether you understand team-level quality gates — the agreements that keep a sprint from collapsing into half-specified tickets and "we'll figure it out in code review" debt.
The two artifacts are Definition of Ready (DoR) — what must be true before a story enters the sprint — and Definition of Done (DoD) — what must be true before a story leaves it. Both are team-owned, not analyst-owned, but the analyst is the person most likely to break a DoR by handing off thin tickets and most likely to be blamed when DoD slips. Knowing the difference between these gates and acceptance criteria — the per-story behavioral checks — is the load-bearing distinction.
Most candidates get the surface answer right and the second-order question wrong. They can recite "DoR is before, DoD is after" but freeze when asked how the team would change its DoR after a sprint where 40% of stories blocked on missing designs. Treat these checklists as living instruments tuned at retros, not laminated wall posters.
Definition of Ready
A Definition of Ready is the set of criteria a story must satisfy before the team will pull it into a sprint. It exists to stop the team from committing to work that is not yet workable. Without a DoR, you ship Mondays where a developer opens a ticket, finds no acceptance criteria, no design, and an unanswered question for the tech lead — then loses three hours waiting for the analyst to respond on Slack.
A typical DoR for a user story looks like this:
- User story is written in a clear "As a / I want / So that" or job-story format.
- Acceptance criteria are written and reviewed with engineering.
- Design assets are attached or marked not-needed.
- Upstream and downstream dependencies are identified.
- Technical approach is sanity-checked with the tech lead.
- Story points are estimated by the team.
- All stakeholders are tagged and have signed off where needed.
Sanity check: if a developer reading the ticket alone, with no Slack access, cannot start work, the story has failed the DoR — no matter how many boxes are ticked.
DoR is enforced in refinement (sometimes called grooming) — a recurring meeting where the team walks the backlog, asks questions, and either marks a story Ready or kicks it back. A team with a strong refinement cadence rarely has stories die mid-flight.
Definition of Done
A Definition of Done is the set of criteria that must be true for a story to be counted as delivered. It is the team's quality contract with the product and with itself. DoD lives across all stories — it is not redefined per ticket — which is precisely what makes it different from acceptance criteria.
A representative DoD for a backend-heavy team:
- Code is written and merged to the main branch.
- Code review approved by at least two engineers.
- Unit and integration tests added and passing in CI.
- Documentation updated (README, runbook, or internal wiki).
- Acceptance criteria verified by QA or the analyst.
- Deployed to staging and smoke-tested.
- Performance check passed if the story has non-functional requirements.
- Security review done if the story touches sensitive data or auth.
- Monitoring and alerting in place for new endpoints or jobs.
DoD is what protects the team from the slow drift into legacy hell. Skip the tests once "because the deadline is Friday" and you have not actually finished the work — you have borrowed against your future sprint capacity. A good systems analyst pushes back on that trade publicly, in the standup, with the DoD as the reference document.
The DoD applies to every story, every time, with no per-ticket negotiation — that is what makes it a definition and not a wish list.
DoR vs DoD vs acceptance criteria
This is the question that separates candidates who memorized a blog post from candidates who have run sprints. The three artifacts live at different scopes and different points in the lifecycle.
| Aspect | DoR | DoD | Acceptance Criteria |
|---|---|---|---|
| When it applies | Before sprint start | Before story closes | Throughout the story |
| Scope | Every story on the team | Every story on the team | One specific story |
| Author | Team agreement at retro | Team agreement at retro | Systems analyst with PM |
| What it checks | Workability of the input | Quality of the output | Behavior of the feature |
| Example item | "AC are written" | "Tests are passing" | "When user clicks Submit, a confirmation email arrives within 60 seconds" |
| Failure mode if missing | Sprint commitments collapse | Tech debt and prod bugs | Engineering builds the wrong thing |
The trick is realizing that DoR and DoD are team-scoped and uniform, while acceptance criteria are story-scoped and bespoke. If your interviewer asks "what if a story has acceptance criteria but is not Ready," the answer is: AC may be one line item inside the DoR ("AC are reviewed with engineering"), but AC alone do not satisfy DoR — you still need estimates, dependencies, designs, and stakeholder sign-off.
Gotcha: candidates often say "DoD is just the AC plus tests." It is not. The DoD includes operational concerns — monitoring, runbooks, security review — that no individual story would ever spell out in its AC.
Worked story example
Let's make this concrete with a realistic story you might see in a SA interview.
Story: As a registered user, I want to reset my password through an email link, so that I can regain access when I forget my credentials.
The DoR for this story might look like:
- [x] User story written in As-a / I-want / So-that form.
- [x] AC drafted in Given/When/Then (see below).
- [x] Email template approved by content design.
- [x] Backend endpoint /auth/reset-password discussed with tech lead.
- [x] Rate-limit policy agreed with security (max 5 requests / hour / IP).
- [x] Story points estimated: 5.
- [x] Dependencies confirmed: SendGrid integration already live.The acceptance criteria — the per-story behavior — are written in Given/When/Then:
Scenario 1: Successful reset request
Given a registered user is on /forgot-password
When they enter a known email and submit
Then they receive an email with a reset link within 60 seconds
And the link expires after 30 minutes
Scenario 2: Unknown email
Given the email is not registered
When the user submits the form
Then the UI shows "If the email exists, a link has been sent"
And no email is sent
Scenario 3: Rate limit
Given the user has submitted 5 requests in the last hour
When they submit a 6th request
Then they get a 429 response with a Retry-After headerThe DoD for the same story, applied uniformly with every other story in the sprint:
- [x] Code merged with two approvals.
- [x] Unit tests for token generation and expiry.
- [x] Integration test covering all three AC scenarios.
- [x] Email renders correctly in Gmail, Outlook, and iOS Mail.
- [x] Security review of token entropy and rate-limit middleware.
- [x] Datadog dashboard updated with reset-request rate and failure rate.
- [x] Runbook entry on how to manually invalidate a token.
- [x] Deployed to staging and smoke-tested by QA.Notice how the three artifacts answer three different questions: DoR — is this story workable? AC — does the feature behave correctly? DoD — is the work production-grade? A senior systems analyst can hold all three in mind without flattening them into one checklist.
When to update DoR and DoD
Both documents are living — they exist to be edited at retrospectives. A team that has never changed its DoR or DoD since onboarding is a team that is either lucky or not paying attention. Real signals that trigger an update:
- Half the sprint blocks on missing wireframes. Add a "design attached or marked not-needed" line to DoR.
- Production bugs trace back to untested edge cases. Tighten the test-coverage line in DoD, or add an explicit "edge cases listed in AC" line to DoR.
- Performance regressions ship to prod. Add a load-test step to DoD for any story touching the hot path.
- Onboarding new engineers takes too long. Add a documentation line to DoD.
- Refinements run long because stories arrive raw. Tighten the analyst-side prep checklist that feeds DoR.
A practical norm: review DoR and DoD every 3 to 5 sprints, not every retro. Change them too often and the team stops trusting them; never change them and they decay into folklore.
Common pitfalls
The most common failure in real teams is no DoR or DoD at all. The team operates on tribal knowledge, every story negotiation is bespoke, and quality is whatever the loudest engineer in standup says it is. The fix is not heroic — write a one-page DoR and a one-page DoD, walk them through in a 45-minute meeting, and enforce them at the next refinement. Imperfect criteria that everyone follows beat perfect criteria living only in Confluence.
A close second is the 30-item DoD that nobody actually runs. Teams build these by adding "one more thing" every retro until engineers silently skip three quarters of the checklist. The fix is to ruthlessly cull: any item that has never failed in the last ten sprints does not belong. Five to ten DoD items, all load-bearing, is the right shape.
The third failure is a DoR so strict that the backlog stops moving. Junior analysts love adding "PM confirmed OKR alignment" or "legal review complete" — items that block everything for the tiny fraction of stories that need them. The fix is to split: a baseline DoR for all stories, plus an extension for high-risk stories. Calibrate the bar to the story, not the other way around.
A fourth trap is ignoring DoD under deadline pressure. "We'll add the tests next sprint" is the single most expensive sentence in software engineering — it converts a delivery deadline into a permanent tax on every future change. A systems analyst with the right backbone says no, in standup, with the DoD as cover. If management overrides, log it as a deliberate exception, not a quiet skip.
Finally, one DoD for all story types compounds over time. A typo fix and a new payment integration cannot reasonably share the same checklist. The cleanest pattern is a baseline DoD plus type-specific extensions: bug fixes need a regression test, new features need monitoring, schema changes need a rollback plan.
Related reading
- Acceptance criteria with Given/When/Then for systems analysts
- As-is to be analysis for systems analysts
- Case interview for systems analyst
- Change management for systems analysts
If you want to drill systems analyst questions like this every day, NAILDD is launching with 1500+ interview problems across exactly this pattern.
FAQ
Are DoR and DoD the same for a bug ticket as for a feature story?
No, and pretending they are is a quick way to ship bad fixes. A bug's DoR should require steps to reproduce, the environment where the bug shows, the severity classification, and a link to the user report or alert. A bug's DoD should require a regression test that fails before the fix and passes after, plus an explicit check that the fix did not regress any related path. Feature DoD covers things like monitoring and runbooks that rarely apply to small bug fixes.
Who owns the DoR and DoD?
The team owns both, but the systems analyst (or product manager if there is no SA) is usually the steward — the person who proposes changes at retros, keeps the documents current, and pushes back when someone tries to skip them. Ownership being shared is what gives the documents legitimacy; one person editing them unilaterally is how they become wallpaper.
Should the DoR include "all acceptance criteria are written"?
Yes, but only as one of several items, not as a synonym for DoR. Writing AC is necessary for a story to be Ready, but it is not sufficient — you still need designs, estimates, dependencies, and stakeholder sign-off. Conflating the two is the most common conceptual error in junior SA interviews.
What's the difference between DoD and "definition of release"?
DoD is per-story and per-sprint: the work is complete and on staging. Definition of Release is the broader gate before a feature actually goes to production users — things like A/B test setup, feature-flag wiring, marketing readiness, and customer-support training. Some teams collapse the two; in larger orgs they are kept separate so that small stories can finish without waiting on launch logistics.
How do you describe DoR and DoD without sounding rote?
Anchor every answer in a story you've actually run. "Our DoR required a design link, and after a sprint where two stories blocked on missing Figma files we made designs a hard ticket requirement, not a standup mention." A concrete update beats a textbook definition every time.