Planning Poker Estimation Facilitator
Facilitate story-point estimation using Planning Poker, uncertainty and delivery complexity.
Act as an experienced Scrum Master and Planning Poker facilitator.
Facilitate estimation for the following backlog item:
{{backlog_item}}
Acceptance criteria:
{{acceptance_criteria}}
Known technical context:
{{technical_context}}
Dependencies and constraints:
{{dependencies_and_constraints}}
Team reference stories:
{{reference_stories}}
Analyze estimation factors across:
1. Scope
2. Business Complexity
3. Technical Complexity
4. Integration Complexity
5. Data Complexity
6. Testing Effort
7. Dependencies
8. Uncertainty
9. Operational Impact
10. Security and Compliance
11. Team Familiarity
12. Delivery Risk
Use the following Fibonacci scale:
1, 2, 3, 5, 8, 13, 21
Do not estimate time in hours or days.
Do not treat story points as a direct measure of duration.
Create:
1. Story Summary
2. Estimation Factors
3. Questions Before Voting
4. First Planning Poker Vote
5. Reasons for Low Estimates
6. Reasons for High Estimates
7. Sources of Disagreement
8. Recommended Discussion
9. Suggested Consensus Range
10. Final Suggested Story-Point Value
11. Confidence Level
12. Assumptions
13. Risks
14. Story-Splitting Recommendation
If critical information is missing, do not force an estimate.
Instead return:
Not Ready for Estimation
and list the information required.
A value of 13 or 21 should trigger a story-splitting recommendation unless there is a clear reason to retain the item.
Use reference stories when provided.
Make it clear that the final estimate belongs to the delivery team, not to the facilitator or AI.
Return a structured Planning Poker facilitation summary.Works with ChatGPT, Claude, Gemini and Copilot.
Example in action
See how this prompt transforms a real input into a structured result.
Backlog item: As a customer, I want to reset my forgotten password through email verification, So that I can regain access to my account. Acceptance criteria: - A reset link is sent to the registered email address. - The link is single-use. - The link expires after a configured period. - A generic response is shown for unknown email addresses. - The new password must satisfy the password policy. Technical context: The authentication service already supports password updates, but no reset-token mechanism exists. Dependencies: Email service and security review. Reference stories: Profile editing was estimated at 3 points. Email-address verification was estimated at 5 points.
Estimation Readiness: Ready for Estimation Key Estimation Factors: Business Complexity: Medium Technical Complexity: Medium to High because a secure reset-token mechanism does not yet exist. Integration Complexity: Medium because the story depends on the email service. Testing Effort: High because positive, negative, expiry, reuse and account-enumeration scenarios must be tested. Questions Before Voting: - What is the reset-link expiration period? - Is rate limiting required? - Does the email service already provide a suitable template? - How are reset events audited? Likely Votes: 5: If token generation and email integration are straightforward. 8: If security controls, auditing and rate limiting must be implemented. Suggested Consensus Range: 5–8 Suggested Story-Point Value: 8 Confidence: Medium Important: The final estimate should be agreed by the delivery team after the open security questions are answered.