HKSM

People Requirements are the documented capabilities, capacity, and constraints needed to compose and support the Scrum Team(s) for a product or release. They outline team size, key skills, availability, and conditions such as location or compliance to guide team formation, staffing, and training decisions.

Key Points

• Input to Form Scrum Team and Identify Scrum Master and Stakeholder(s); often initiated during Create Project Vision and refined in Release Planning.
• Describes needed capabilities and capacity, not specific names or rigid role titles.
• Ensures cross-functional coverage required to meet the Definition of Done.
• Includes availability, dedication level, location and time zone, language, and compliance constraints.
• Iterative and living document that evolves with the product backlog and release goals.
• Used by the Product Owner, Scrum Master, and stakeholders to plan staffing, onboarding, and training.

Purpose

Provide a clear, lightweight reference for what people capabilities are needed to deliver valuable increments. Align team composition and capacity with product goals, guide staffing decisions, and surface constraints early so that risks can be addressed before sprinting begins.

In multi-team efforts, help coordinate skills across teams and shared services to avoid bottlenecks and uncovered work.

Key Terms & Clauses

• Capability set: development, testing, UX, data, DevOps, domain expertise, and any specialized compliance skills.
• Capacity and dedication: estimated team size, number of teams, and expected full-time commitment per person.
• Cross-functionality: preference for T-shaped skills to reduce handoffs and increase flexibility.
• Constraints: time zones, co-location needs, security clearance, tool access, and language requirements.
• Availability windows: overlap needed for Scrum events and pair/mob work.
• DoD coverage: confirmation that skills exist to satisfy Definition of Done and critical non-functional requirements.

How to Develop/Evaluate

1. Review the Product Vision, epics, and key non-functional requirements to understand the delivery scope.
2. List required capabilities to build, test, integrate, and release potentially shippable increments.
3. Estimate capacity: target team size and number of teams based on historical velocity or forecasting assumptions.
4. Capture constraints: dedication level, location and time zone overlap, compliance needs, and tool access.
5. Validate with the Product Owner, Scrum Master, and key stakeholders (e.g., HR, security, architecture).
6. Reassess during Release Planning and whenever backlog priorities or constraints materially change.

How to Use

• Identify Scrum Master and Stakeholder(s): select a Scrum Master with suitable facilitation and domain context and confirm stakeholder groups needed for collaboration.
• Form Scrum Team: guide staffing, onboarding, and training so the team is cross-functional and dedicated.
• Release Planning: check whether capacity aligns with release goals; trigger training, hiring, or vendor sourcing if gaps exist.
• Sprint Planning and ongoing delivery: verify availability changes, adjust scope ordering, and address skill gaps via pairing, mentoring, or targeted coaching.
• Scaling: coordinate capabilities across multiple teams and define shared services or communities of practice.

Example Snippet

• Team composition: 1 Product Owner, 1 Scrum Master, 5 Developers (cross-functional), 1 QA automation specialist.
• Capabilities: backend API, UI, test automation, UX, DevOps, data modeling.
• Availability: 7 full-time equivalents; minimum 4-hour daily overlap between GMT+1 and GMT-5 for Scrum events.
• Constraints: access to staging and CI/CD tools; privacy compliance training required within first sprint.
• Success condition: skills cover Definition of Done including performance and security checks.

Risks & Tips

• Anti-pattern: listing specific names instead of capabilities leads to rigidity and bottlenecks.
• Over-specialization creates handoffs; prefer T-shaped team members to maintain flow.
• Part-time allocations and context switching reduce predictability; aim for dedicated team members.
• Ignoring non-functional needs (e.g., security) causes rework; include them explicitly.
• Failing to update People Requirements as the backlog evolves undermines planning accuracy.
• Use a simple skills matrix to visualize coverage and guide targeted coaching or hiring.

PMP/SCRUM Example Question

During Release Planning, forecasted velocity shows the current single-team setup will not meet the desired release date. The Product Owner asks the Scrum Master how to respond. What is the best action using People Requirements?

1. Extend the sprint length from 2 weeks to 4 weeks to get more done per sprint.
2. Update People Requirements to propose a second cross-functional team and identify training or sourcing to cover missing skills.
3. Add mandatory overtime to increase output without changing team structure.
4. Add two part-time specialists to the existing team to cover gaps.

Correct Answer: B — Update People Requirements to propose a second cross-functional team and identify training or sourcing to cover missing skills.

Explanation: People Requirements guide capacity and capability decisions; scaling with another cross-functional team and closing skill gaps aligns with Scrum practices better than extending sprints, overtime, or part-time additions.