HKSM

A transparent record of who is available, for how long, and the team’s agreed scope commitment for a sprint or release. It is used to calculate capacity, select user stories, and forecast delivery, and is updated when availability or priorities change.

Key Points

• Captures team members’ availability and the team’s commitment for the sprint or release in one place.
• Serves as an input to Release Planning and Sprint Planning, and as an output when the team finalizes its sprint commitment.
• Includes planned leave, public holidays, training, partial allocations, and focus factors to derive realistic capacity.
• Guides Product Owner decisions on how many user stories to pull based on empirical capacity and velocity.
• Supports daily inspection and adaptation when availability changes or impediments reduce capacity.
• Links to other artifacts such as the Sprint Backlog, Release Planning Schedule, and Impediment Log.

Purpose

The main purpose is to enable realistic planning and clear expectations by making availability constraints and the team’s commitment visible. It helps avoid overcommitting, protects quality, and aligns stakeholders on what is feasible within the timebox.

It also enables empirical forecasting across releases by combining availability with historical velocity, allowing adjustments when team size or focus changes.

Key Terms & Clauses

• Availability - The time a person can dedicate to Scrum work during a sprint, accounting for leave, meetings, and other duties.
• Focus factor - A percentage adjustment to reflect time lost to ceremonies, support, and context switching.
• Capacity - Team-available hours or ideal days in the sprint after applying availability and focus factor.
• Commitment - The team’s agreed set of user stories and a sprint goal they pledge to deliver within the sprint.
• Partial allocation - When a member is shared across teams or initiatives, reducing effective availability.
• Time-off calendar - A simple calendar noting holidays, vacations, and training that reduce capacity.

How to Develop/Evaluate

1. Collect calendars - Gather team members’ planned leave, holidays, training, and any partial allocations for the sprint window.
2. Count working days - Determine working days in the sprint and subtract known non-working time.
3. Apply focus factor - Deduct typical time for ceremonies, support, and context switching to avoid optimistic capacity.
4. Compute capacity - Convert to team-available hours or ideal days and validate against recent velocity and throughput.
5. Assess skills and constraints - Note skill-based bottlenecks, handoffs, and external dependencies that may limit flow.
6. Confirm with the team - Review and adjust collaboratively, then document a clear capacity range and preliminary commitment.

How to Use

During Release Planning, use the availability data and historical velocity to build a release forecast and adjust scope or timelines. In Sprint Planning, use the capacity figure to select user stories from the prioritized product backlog and form a realistic sprint goal.

• Input to Commit User Stories - Guides which stories the team can responsibly commit to.
• Input to Create Sprint Backlog - Informs task breakdown to fit within available capacity.
• Support for Estimate Tasks - Helps distribute tasks based on skill availability and focus.
• Ongoing control in Daily Standup - Update when impediments or changes reduce capacity; re-plan work as needed.
• Feedback in Retrospect Sprint - Compare planned versus actual availability to refine focus factor and future commitments.

Example Snippet

Sample sprint capacity note for a 10-working-day sprint:

• Team members: 5. Ceremonies/support focus factor: 80%.
• Known time off: 1 member off 2 days; 1 member 50% allocated elsewhere.
• Raw team-days: 5 × 10 = 50. Adjust for time off: 50 - 2 - 5 = 43 team-days.
• Effective capacity: 43 × 0.8 = 34.4 team-days (round to 34).
• Sprint commitment: Select user stories whose estimated effort totals about 30-34 team-days with a clear sprint goal.

Risks & Tips

• Risk of overcommitment if ceremonies, support, and multitasking are not factored in; apply a realistic focus factor.
• Risk of skill bottlenecks; balance work across skills and reduce single-specialist dependencies.
• Outdated calendars lead to inaccurate forecasts; update availability whenever plans change.
• Pressure to keep velocity constant despite fewer people; negotiate scope using transparent capacity data.
• Do not equate commitment with promise at all costs; protect quality and sustainability.
• Track planned versus actual capacity each sprint to improve future planning accuracy.

PMP/SCRUM Example Question

During Sprint Planning, two developers are scheduled for a 2-day training and one tester is only 50% available this sprint. The Product Owner wants to keep the same number of user stories as last sprint. What should the Scrum Master do?

1. Keep the same commitment because the team should maintain velocity.
2. Extend the sprint length to accommodate the reduced availability.
3. Adjust capacity based on availability and facilitate negotiation of a smaller, achievable scope.
4. Plan overtime to meet the original number of user stories.

Correct Answer: C — Adjust capacity based on availability and facilitate negotiation of a smaller, achievable scope.

Explanation: People Availability and Commitment is an input to Sprint Planning and Commit User Stories. The team should set scope based on realistic capacity, not force the previous sprint’s volume.