HKSM

Resource Requirements are a concise list of the skills, roles, tools, environments, and quantities needed to implement selected backlog items. In SBOK, they are produced during planning and estimating and used as inputs to sprint planning, procurement or access arrangements, and impediment management.

Key Points

• Describes what resources are needed, in what quantity, and for how long to deliver user stories and tasks.
• Created during Plan and Estimate processes (e.g., Identify Tasks and Estimate Tasks) and refined in Sprint Planning.
• Acts as an input to Create Sprint Backlog, Release planning, and coordination for tools, licenses, and environments.
• Focuses on skills and capabilities, not assigning specific people, to respect team self-organization.
• Includes non-people needs such as test environments, data, equipment, and external services.
• Updated throughout the sprint as knowledge improves and impediments are discovered or removed.

Purpose

Provide a clear, time-bound view of the resources necessary to complete selected backlog items so the team can make a realistic sprint commitment. Surface gaps early, align capacity with scope, and trigger timely actions for access, procurement, or risk mitigation.

This artifact links work to the practical means of doing it, reducing surprises during implementation and enabling the Scrum Master to address constraints quickly.

Key Terms & Clauses

• Role vs. named person: specify roles or skills needed (e.g., UX, DevOps) rather than individuals.
• Quantity and duration: indicate amounts and time windows (e.g., 1 tester for 2 days in week 2).
• Non-people resources: tools, licenses, test data, devices, environments, and integrations.
• Lead time: expected time to obtain access or equipment, used to plan ahead and raise risks.
• Constraints and assumptions: capacity limits, vendor schedules, or shared-resource policies.
• Traceability: link each requirement to a user story, task, or epic for transparency and control.

How to Develop/Evaluate

Start from prioritized user stories and their acceptance criteria. Break stories into tasks, estimate task effort, and identify the skills, tools, and environments required.

• Gather inputs: Prioritized Product Backlog, Definition of Done/Ready, team skills matrix, and historical velocity.
• For each task, record role/skill, quantity, duration, time window, and any non-people resource needs.
• Check availability against sprint capacity and calendars; note lead times for external items.
• Review as a team during Sprint Planning; the Scrum Master flags risks and impediments.
• Evaluate for sufficiency and realism; simplify to the minimum detail that supports decisions.

How to Use

Use Resource Requirements to confirm the sprint commitment and to finalize the Sprint Backlog. Where gaps or long lead times exist, raise impediments and plan mitigation.

• Input to Create Sprint Backlog and Commit User Stories by validating capacity and readiness.
• Trigger requests for environments, access, or licenses; coordinate with support teams or vendors.
• Guide Daily Standup discussions when resource constraints block tasks.
• Feed Release planning by highlighting skills bottlenecks that affect sequencing.
• Update continuously as scope changes, tasks split, or impediments are resolved.

Example Snippet

Story US-143: As a user, I can reset my password.

• Roles/skills: 1 backend dev (2 days), 1 QA (1 day), 1 DevOps (0.5 day).
• Non-people: Test email server, staging environment with SMTP access, test data set.
• Time window: DevOps needed by day 2 for environment variables; QA in days 3-4.
• Lead time: SMTP access approval requires 2 business days - request at sprint start.

Risks & Tips

• Risk: Over-specifying named individuals undermines self-organization. Tip: specify skills and time windows.
• Risk: Ignoring non-people resources causes late blockers. Tip: include environments, data, and licenses.
• Risk: Static requirements become outdated. Tip: revisit in Daily Standups and update promptly.
• Risk: Hidden lead times delay delivery. Tip: capture and act on access/procurement lead times early.
• Risk: Mismatch with capacity inflates commitments. Tip: validate against team availability and velocity.
• Risk: Tooling conflicts across teams. Tip: coordinate shared resources and set usage windows.

PMP/SCRUM Example Question

During Sprint Planning, the team selects a story that needs a dedicated test environment and a short-term security review. Which artifact should capture the specific skills, quantities, and time windows to plan these needs and trigger any access requests?

1. Sprint Backlog.
2. Definition of Done.
3. Resource Requirements.
4. Impediment Log.

Correct Answer: C — Resource Requirements

Explanation: Resource Requirements record the needed skills, tools, and non-people resources with quantities and timing, enabling planning and requests. The Impediment Log tracks blockers, not the detailed resource plan; the Sprint Backlog lists the work, and the Definition of Done lists quality criteria.