DEV Community: keyur shah

Story Points vs Hours: Why Switching Improves Estimation

keyur shah — Sun, 11 Oct 2026 05:22:42 +0000

Estimating work is a core activity for any agile team, yet many still default to hours. The shift to story points often feels risky at first, but teams that make the change usually see more reliable forecasts. Below is a practical breakdown of the differences, why points work better, and how to use them effectively.

Hours

Measures time – An estimate expressed in hours claims to predict the exact amount of clock time a task will take.
Assumes uniform working speed – The calculation presumes every developer works at the same pace, which rarely holds true.

Because hours tie directly to individual capacity, the same “8‑hour” story can feel easy for a senior engineer and overwhelming for a junior one. This mismatch introduces hidden bias and makes cross‑person comparison noisy.

Story Points

Measures relative effort – Points capture the combination of complexity, risk, and unknowns rather than raw time.
Team‑relative, not universal – A “5” for one team may be a “3” for another; the scale is calibrated internally.

By focusing on effort rather than duration, points let the team discuss the nature of the work without getting stuck on personal speed.

Why Points Work Better

Removes false precision – No one pretends a story is exactly “6.5 hours.” Point values are coarse, encouraging discussion over exactness.
Averages out over a sprint – Individual estimation errors tend to cancel each other when summed across a sprint, producing a stable velocity trend.

This collective smoothing makes planning more predictable than aggregating many hour estimates that each contain personal bias.

Using Fibonacci

1, 2, 3, 5, 8, 13… – The Fibonacci sequence creates widening gaps as numbers grow, reflecting decreasing certainty for larger items.
Anything above 13 gets split – Stories that would require a value higher than 13 are usually broken into smaller pieces, because they become too hard to estimate reliably as a single unit.

The sequence forces the team to think critically about size and to avoid lumping disparate work into one massive story.

Do / Avoid

Recalibrate points with a reference story the team agrees on.
Re‑estimate if scope changes mid‑sprint.
Track velocity trend over multiple sprints, not any single sprint.

Avoid

Converting points back to hours for individual tracking.
Comparing velocity across different teams.
Letting one person’s estimate override the team’s during planning poker.

When teams respect these guidelines, story points become a powerful, shared language for forecasting work.

Switching to points shifts the focus from “how long” to “how hard,” and that shift is what drives better estimates.

Book a call

The Test Pyramid

keyur shah — Sat, 10 Oct 2026 07:11:52 +0000

Why “more E2E tests” is usually the wrong answer to flaky releases

In fast‑moving product teams the instinctive reaction to flaky releases is to add more end‑to‑end (E2E) tests. The result is often a massive, brittle UI suite that slows down feedback loops and inflates maintenance costs. The test pyramid reminds us that the shape of our test suite matters: the bulk of verification should happen low in the stack, while only a few critical user journeys belong at the top.

Unit (Base)

Unit tests are the foundation of a healthy pyramid. They run in milliseconds, allowing thousands to execute on every commit. Because they are fast and isolated, they give developers immediate confidence that a single function or class behaves as expected. The code that defines the behavior also owns the tests, so they are written side‑by‑side with the implementation. This tight coupling makes it easy to refactor without breaking the test suite and keeps the cost of adding coverage low.

Integration (Middle)

Integration tests sit above unit tests and verify that multiple components work together. Typical concerns include API contracts, database interactions, and service calls. They are fewer in number than unit tests but more numerous than E2E tests, forming the middle tier of the pyramid. By exercising real communication paths (e.g., a repository calling a mock service), integration tests catch mismatches that unit tests cannot see, such as serialization errors or contract violations. They provide a safety net before a scenario reaches the UI layer.

E2E / UI (Top)

E2E tests simulate full user journeys through the real UI. They are the slowest and most brittle part of the suite because they depend on browsers, network latency, and external services. Consequently, only a small set of critical happy‑path scenarios should be covered here—things like “user can sign up and log in” or “checkout completes successfully.” By limiting the number of E2E tests, teams keep the feedback loop short and reduce flaky failures caused by environmental factors.

Why the Shape Matters

An inverted pyramid—many UI tests and few unit tests—produces a slow, flaky suite that erodes developer confidence. When bugs are pushed up the pyramid, they become expensive to detect; a failure that could have been caught in a millisecond unit test now costs minutes of CI time and fragile UI maintenance. Maintaining a proper pyramid ensures that cheaper, faster tests catch most defects, leaving only the most valuable end‑to‑end scenarios for the top layer.

Do / Avoid

Keep E2E suites small and focused on critical‑path scenarios.
Push edge‑case coverage down to unit or integration tests where they run quickly and deterministically.
Track flaky test rates per layer separately to identify where instability originates.

Avoid

Chasing 100 % E2E coverage; it does not scale and adds unnecessary brittleness.
Skipping integration tests to jump straight to E2E; this creates gaps in contract verification.
Treating the pyramid shape as immutable; revisit the distribution as the codebase and team evolve.

A well‑shaped test pyramid gives fast feedback, reduces flakiness, and lets teams ship with confidence.

Book a call

Sprint Planning Anatomy: What Really Happens in Those Two Hours

keyur shah — Fri, 09 Oct 2026 03:43:31 +0000

Sprint planning often feels like a “pick some stories” ritual, but a well‑structured session can set the tone for the entire iteration. Below is a practical walkthrough of the three essential parts of a two‑hour sprint planning meeting, the inputs you need, and the pitfalls to avoid.

Part 1: The What

Product Owner presents priority backlog – The PO should bring a refined set of items that already meet the Definition of Ready (DoR). This means acceptance criteria are clear, dependencies are identified, and any necessary designs are attached. The team can then focus on understanding, not polishing, the work.
Team confirms sprint goal – Together, the team crafts a single sentence that captures the desired outcome of the sprint (e.g., “Enable users to reset passwords via email”). The goal provides a north‑star that guides selection and prevents the meeting from devolving into a mere story count exercise.

Part 2: The How

Team breaks stories into tasks – Once the goal and backlog items are agreed upon, developers discuss the technical approach and split each story into 4‑8 hour tasks. The discussion is collaborative; the PO does not dictate implementation details, but the team ensures the work is feasible within the sprint.
Capacity checked against commitment – The team reviews each member’s real availability, accounting for vacations, on‑call duties, and scheduled meetings. This “real days available” figure replaces the naïve headcount × 10‑hour rule and keeps the commitment realistic.

Inputs Needed

Refined, estimated backlog – All stories should be sized during the prior refinement session. Estimating for the first time in planning consumes precious minutes and often leads to inaccurate forecasts.
Team capacity for the sprint – Calculate the actual number of person‑days each member can contribute, not the theoretical maximum. This figure drives how many story points the team can responsibly pull in.

Common Failure Modes

Refinement happening live – Trying to refine items on the spot stretches a two‑hour planning meeting into a four‑hour marathon and leaves the team fatigued.
No sprint goal set – Without a clear goal, the team tends to optimize for story count rather than delivering a cohesive outcome, resulting in scattered effort and lower value.

Do / Avoid

Finish refinement before planning starts.
Set one clear sprint goal, not just a task list.
Check real capacity, not theoretical capacity.

Avoid

Estimating stories for the first time during planning.
Overcommitting to hit a velocity number.
Skipping the sprint goal; it’s not an optional ceremony.

A focused sprint planning session that respects these steps turns a routine meeting into a strategic launchpad for the next two weeks. Keep the agenda tight, the inputs ready, and the goal front‑and‑center, and the team will leave the room with confidence—not a to‑do list.

Book a call

The Defect Life Cycle: A Practical Guide for Any Tracking Tool

keyur shah — Thu, 08 Oct 2026 15:58:01 +0000

Every software project generates bugs, and regardless of whether you use Jira, Azure DevOps, or a simple spreadsheet, each defect follows a predictable path. Understanding the states, ownership, and best practices helps teams move faster, keep quality metrics honest, and avoid the common pitfalls that turn defect tracking into a nightmare.

The Core States

New → Assigned – When a tester discovers an issue, they log it as New and provide clear reproduction steps and evidence. The triage lead reviews the report, assigns a severity, and hands the defect to a developer, changing the status to Assigned.

Fixed → Retest – The developer investigates, writes a fix, and updates the defect to Fixed. At this point the responsibility shifts back to QA, which must retest using the original steps. The status becomes Retest to signal that verification is pending.

Retest Outcomes

Verified → Closed – If QA confirms that the fix resolves the problem and no side effects appear, the defect moves to Verified and then Closed. The issue is considered done.

Reopened – When the fix does not hold—perhaps the bug reappears in a different scenario or the original steps fail—QA changes the status to Reopened. The defect returns to Assigned for another round of investigation.

The Other Exits

Duplicate – Occasionally a defect is already recorded under another ID. Marking it as Duplicate consolidates effort and keeps the backlog clean.

Won’t Fix / Deferred – Some defects are accepted as risk or postponed for a later release. They receive a Won’t Fix or Deferred status, but should still be reviewed periodically to ensure the decision remains valid.

Who Owns What

QA owns New, Retest, Verified – QA is responsible for initially finding the defect, confirming that a fix works, and finally verifying closure.
Dev owns Assigned, Fixed – Developers diagnose the root cause, implement the fix, and update the defect accordingly.

Do / Avoid

Attach reproducible steps and supporting evidence at New; never wait until later stages.
Re‑verify the exact original steps during Retest; a quick glance can miss regressions.
Track the reopen rate per component; a high rate signals deeper quality issues.

Avoid

Closing a defect without an independent retest; this creates hidden technical debt.
Letting Won’t Fix become a dumping ground; periodically review these items.
Skipping severity logging at creation time; severity drives prioritization and resource allocation.

A well‑defined defect life cycle keeps the whole team aligned, reduces waste, and turns bugs into measurable improvement signals.

Book a call

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)