HKSM

A Proof of Concept (PoC) is a small, time-boxed experiment or prototype used to demonstrate technical or business feasibility for an epic or high-risk user story. It reduces uncertainty and feeds decisions on prioritization, estimation, and release planning.

Key Points

• Time-boxed experiment or prototype aimed at validating feasibility, not a shippable increment.
• Targets high-risk assumptions in epics or user stories (technology, integration, performance, usability).
• Produces findings, evidence, and a recommendation that inform backlog priorities and estimates.
• Often created as an output of a research spike and used as an input to backlog refinement and release planning.
• Product Owner frames the question and decision needed; Developers execute; Scrum Master facilitates.
• Success criteria are defined upfront to enable a clear go/no-go or pivot decision.

Purpose

The main purpose is to de-risk key choices early and cheaply before committing significant effort. A PoC helps validate a solution approach, architecture, or vendor integration so the team can plan realistic scope and timelines.

By converting uncertainty into data, the Scrum Team can refine the product backlog, improve estimates, and set more reliable release goals.

Key Terms & Clauses

• Spike: A time-boxed research or technical exploration that may produce a PoC as an output.
• Hypothesis statement: A concise claim the PoC will test (e.g., "Service X can process 500 TPS with latency under 200 ms").
• Success criteria: Evidence-based thresholds that determine whether the hypothesis is met.
• Technical feasibility: The solution can be built with acceptable performance, security, and compatibility.
• Business viability: The approach supports expected value, cost, and compliance needs.
• PoC vs MVP: PoC proves feasibility; MVP is a minimal releasable product that delivers real user value.

How to Develop/Evaluate

1. Define the decision to be made, the hypothesis to test, and measurable success criteria.
2. Time-box the effort and limit scope to the smallest experiment that can produce evidence.
3. Build a minimal prototype or run targeted tests (e.g., integration call, load test, security check).
4. Capture objective data, constraints, and unexpected findings; include screenshots, logs, metrics, or code snippets.
5. Evaluate results against success criteria and propose a clear recommendation: proceed, pivot, or investigate further.
6. Share findings in Sprint Review and record them for future reference and onboarding.

How to Use

• As an output: Often produced during Develop Epics or a spike in early sprints to explore risky options.
• As an input: Guides Create Prioritized Product Backlog by adjusting value, risk, and priority of epics and user stories.
• As an input: In Estimate User Stories to refine size and complexity based on proven feasibility and constraints.
• As an input: In Conduct Release Planning to set realistic scope, dates, and dependencies informed by evidence.
• Risk management: Adds, updates, or closes risks and assumptions in the risk register and product backlog.
• Backlog refinement: Triggers splitting or rewriting user stories and updating acceptance criteria derived from PoC learnings.

Example Snippet

User story (spike): As a team, we need to verify that the payment service handles 300 TPS with under 250 ms latency so we can plan the checkout epic.

• Time-box: 2 days.
• Success criteria: 300 TPS, p95 latency <= 250 ms, error rate < 0.5%.
• Outcome: Achieved 320 TPS, p95 = 240 ms, error = 0.3%; recommend proceeding with service X, add throttling task.
• Impact: Increase story estimates for integration by 2 points; prioritize throttling and monitoring tasks in next sprint.

Risks & Tips

• Risk: Treating a PoC as production-ready code. Tip: Label it explicitly as throwaway or refactor-only if reused.
• Risk: Scope creep. Tip: Keep a strict time-box and a single hypothesis.
• Risk: Ambiguous outcomes. Tip: Define measurable success criteria and decision rules upfront.
• Risk: Hidden costs later. Tip: Document shortcuts, assumptions, and technical debt introduced by the PoC.
• Tip: Make PoC results visible in Sprint Review and update backlog items and release plans immediately.
• Tip: Prefer automated, repeatable tests to make evidence easy to verify.

PMP/SCRUM Example Question

The team must choose between two third-party APIs for a critical epic, but performance and rate limits are unclear. What should the Scrum Team do next?

1. Build a full MVP using one API and release it to users for feedback.
2. Create a time-boxed PoC with clear success criteria to test both APIs, then refine the backlog and estimates.
3. Skip the experiment to avoid lowering velocity and pick the cheaper API.
4. Conduct full user acceptance testing before any technical exploration.

Correct Answer: B — Create a time-boxed PoC with clear success criteria to test both APIs, then refine the backlog and estimates.

Explanation: A PoC is the right tool to validate feasibility and performance quickly; its results inform prioritization, estimation, and release planning. The other options either overbuild, avoid needed learning, or apply testing at the wrong time.