DEV Community: keyur shah

Definition of Ready vs Done: The checklists that keep your sprint clean

keyur shah — Mon, 05 Oct 2026 04:57:34 +0000

In agile teams the terms “Definition of Ready” (DoR) and “Definition of Done” (DoD) are often mentioned together, but they serve distinct purposes. DoR is the gate that lets a story into a sprint; DoD is the gate that lets a story out. Treating them as separate, well‑maintained checklists prevents half‑baked work from contaminating the flow and keeps quality predictable.

Definition of Ready

A story is estimable when the team understands the scope well enough to size it. This means the description is clear, dependencies are identified, and any required designs or data are available. Without this clarity, the team spends sprint time debating what the work actually entails.

Acceptance criteria set means that the product owner has written clear, testable conditions that define when the story is complete. These criteria act as the contract between the PO and the development team and give the QA group a concrete basis for verification.

Definition of Done

Code reviewed & merged ensures that every change meets the team’s quality bar. A peer review catches defects early, enforces coding standards, and guarantees that the code is integrated into the main branch without conflicts.

Tested and demo‑ready requires that QA has passed all acceptance tests and that the increment can be deployed to a staging environment for a stakeholder demo. This eliminates the “it works on my machine” problem and guarantees that the story can be shown to the PO at sprint review.

Who Owns What

The Product Owner owns Ready. The PO is responsible for backlog refinement, ensuring that items meet the DoR before sprint planning. This ownership gives the PO authority to pull items back for clarification rather than forcing them into a sprint.

The Team owns Done. The development team collectively agrees on a DoD that applies to every story. This shared agreement avoids the “done” meaning different things to developers, testers, and the PO.

Why It Matters

Fewer mid‑sprint surprises: A solid DoR stops ambiguous or incomplete stories from entering the sprint, reducing the need for re‑planning or emergency clarification.

Consistent quality bar: A shared DoD ensures that “done” has a single definition across the team, preventing the delivery of work that still needs rework after the sprint ends.

Do / Avoid

Review both checklists during the retrospective, not just once at planning.
Keep DoR light; it is a gate, not an essay.
Make DoD visible on the board so everyone can see the quality expectations at a glance.

Avoid

Don’t let the PO and developers disagree on “done” mid‑sprint. Resolve differences before the sprint starts.
Don’t skip DoR to meet sprint‑planning deadlines; a rushed entry creates hidden work later.
Don’t treat DoD as fixed forever; revisit it when the team’s capabilities or product needs change.

A clear, shared understanding of Ready and Done keeps the sprint predictable, the backlog healthy, and the product moving forward.

Book a call

Equivalence Partitioning & Boundary Value Analysis: Cutting Test Cases Without Cutting Coverage

keyur shah — Sun, 04 Oct 2026 06:54:25 +0000

Testing teams often drown in an ocean of possible inputs. Two classic techniques—Equivalence Partitioning (EP) and Boundary Value Analysis (BVA)—let you pick representative values that still exercise every logical path. Below is a quick guide to applying them together, with a concrete example and practical do‑and‑avoid tips.

What is EP

Split input into classes – Group inputs that should behave the same way. For a numeric field, any value below the lower limit, any value inside the allowed range, and any value above the upper limit form separate equivalence classes.
Test one value per class – One representative value stands in for the whole group. If the class is “valid”, any value inside it should pass; if the class is “invalid”, any value should trigger the same error handling.

What is BVA

Test the edges – Bugs tend to cluster at boundaries rather than in the middle of a range. Checking the limits reveals off‑by‑one errors, rounding problems, and incorrect comparison operators.
Min, min+1, max, max‑1 – The four values that catch most boundary defects. For an inclusive range [min, max], test the exact limits and the values just inside the limits.

Worked Example

Imagine a form field that accepts ages from 18 to 60 inclusive.

Equivalence class	Representative test value
`< 18` (invalid)	17
`18–60` (valid)	30
`> 60` (invalid)	61

Applying BVA adds the four boundary values:

Min: 18 – should be accepted.
Min + 1: 19 – also accepted, confirming the lower edge works.
Max: 60 – should be accepted.
Max ‑ 1: 59 – accepted, confirming the upper edge works.

Together, the test set becomes {17, 18, 19, 30, 59, 60, 61}. It covers all valid and invalid partitions while focusing on the most error‑prone points.

Where It Fits

Use during test design – Apply EP and BVA while you are writing test cases, before any code is executed. This front‑loading reduces the number of tests you need to create later.
Pairs with decision tables – When inputs involve combined conditions (e.g., age and membership level), EP defines the partitions for each dimension, and decision tables help you map the cross‑product of those partitions into a manageable set of test scenarios.

Do / Avoid

Document which class each test case represents, so reviewers can see the rationale behind every value.
Combine EP with BVA for tighter coverage; the boundary tests are simply the edge members of each equivalence class.
Apply the techniques to both valid and invalid input ranges to verify positive and negative paths.

Avoid

Don’t test every value in a class; one well‑chosen representative is enough.
Don’t skip invalid partitions; they are essential for confirming robust error handling.
Don’t treat boundaries as optional edge cases; they are the most likely places for defects.

Use EP to slice the input space and BVA to probe its edges—together they give you maximum confidence with minimal test effort.

Book a call

The three hidden pitfalls that sabotage every API test 🧠

keyur shah — Fri, 25 Sep 2026 16:33:47 +0000

The three hidden pitfalls that sabotage every API test 🧠

Mastering contract validation, data hygiene, and flexible environments eliminates flaky tests and uncovers silent bugs

→ Validate contract before any functional test

→ Use environment variables to switch endpoints

❗ A solid API test foundation saves weeks of debugging later.

❓ Do you lock contracts in your test suite, yes or no?

🔖 Save this one — you’ll want it again next time this comes up.

Agile #Scrum #ProjectManagement #Testing #APITesting

Keyur Shah (Project Manager | Scrum Master (CSM, PSM) | Agile Delivery | EX QA LEAD and AI & Automation Enthusiast)