HKSM

A Pilot Plan is a documented approach for releasing a limited, trial version of the product to a controlled user group to validate functionality, usability, and operational readiness before full rollout. It defines scope, timelines, success metrics, and rollback criteria and links release planning to deployment and acceptance processes.

Key Points

• Describes a limited-scope release to a subset of users before full deployment.
• Typically created during release planning and used during Ship Deliverables and Obtain Customer Acceptance.
• Includes scope, entry and exit criteria, success metrics, monitoring, communications, and rollback steps.
• Owned by the Product Owner; the Scrum Master facilitates; the Scrum Team provides technical details.
• Time-boxed and aligned with the Definition of Done and release criteria for the increment.
• Feedback from the pilot updates the Prioritized Product Backlog and informs subsequent sprints and releases.

Purpose

The plan reduces release risk by validating the product in a real environment with a small, representative user cohort. It ensures that support, training, performance, security, and business workflows are ready for a broader launch.

It also creates a clear go/no-go decision framework using measurable criteria, helping the Product Owner decide whether to scale, iterate, or roll back.

Key Terms & Clauses

• Pilot scope: features, user stories, and epic slices included, plus what is excluded.
• User cohort: target customers, geographies, or internal users participating in the pilot.
• Environment and data: pilot environment, data migration rules, and privacy/compliance constraints.
• Entry criteria: prerequisites such as meeting Definition of Done, passing nonfunctional tests, and stakeholder readiness.
• Exit criteria: measurable success thresholds (e.g., defect rate, NPS/CSAT, performance SLAs) and acceptance conditions.
• Monitoring and metrics: telemetry, usage analytics, error rates, capacity, and support tickets.
• Rollback and contingency: triggers, steps, ownership, and communication plan for reversing the pilot.
• Change control: how pilot learnings create or reprioritize Product Backlog Items.

How to Develop/Evaluate

1. Align with the Release Plan: identify the minimal viable slice (stories) that can validate key assumptions.
2. Select the cohort: pick representative users with clear consent and feedback channels.
3. Define entry/exit criteria: set quantitative thresholds (e.g., P1 defects = 0, P2 defects < 2 per 1,000 sessions, 95th percentile latency < 300 ms).
4. Plan monitoring and support: dashboards, on-call coverage, training, and communication cadence.
5. Document rollback: technical steps, data considerations, and who approves the rollback.
6. Review for completeness: Product Owner validates business measures; Scrum Master checks risks and readiness; Team confirms feasibility.
7. Inspect and adapt: after the pilot, capture findings and update the Prioritized Product Backlog and Release Plan.

How to Use

Use the plan as an input when executing Ship Deliverables to coordinate deployment, communications, and monitoring for the pilot. During the pilot window, track metrics and defects daily and capture user feedback as new or updated Product Backlog Items.

Apply exit criteria to decide on full release, further iterations, or rollback. Feed outcomes into Demonstrate and Validate Sprint and into Retrospect to improve future pilots and release practices.

Example Snippet

• Scope: Stories US-145, US-152; exclude payment gateways for pilot.
• Cohort: 200 internal users in Region A, opt-in only.
• Entry Criteria: DoD met; performance test passed; support runbook approved.
• Success Metrics: P1 defects = 0; CSAT ≥ 4.2/5; error rate ≤ 0.5%.
• Monitoring: Dashboard P-01; daily check at 10:00 and 16:00.
• Rollback: Trigger if P1 defect occurs or latency > 300 ms for 30 minutes; change set revert steps documented.
• Timeline: 10 business days, starting next Monday.
• Ownership: Product Owner decision on exit; DevOps lead executes rollback if triggered.

Risks & Tips

• Pilot cohort not representative, leading to false confidence; diversify users where possible.
• Missing rollback plan creates long outages; always rehearse rollback steps.
• Unclear exit criteria cause debate and delays; define quantitative thresholds upfront.
• Security/privacy oversights with real data; validate compliance and masking rules.
• Under-resourced support during pilot; schedule on-call coverage and response SLAs.
• Failure to capture learnings; time-box a review and convert findings into backlog items.

PMP/SCRUM Example Question

A Scrum Team plans to reduce release risk by deploying a limited set of user stories to a small, representative group before a full rollout. Which artifact best guides scope, metrics, and rollback for this limited release?

1. Sprint Backlog.
2. Pilot Plan.
3. Release Burndown Chart.
4. Definition of Ready.

Correct Answer: B — Pilot Plan

Explanation: A Pilot Plan defines the limited release scope, entry/exit criteria, metrics, and rollback steps. The other options do not provide a structured approach for trial deployment decisions.