HKSM

People Costs is a technique for estimating and tracking the labor expenses of the Scrum Team and key supporting roles across sprints and releases. It uses team capacity, timeboxes, and labor rates to forecast budget needs, burn rate, and cost baselines for agile delivery.

Key Points

• Focuses on labor costs for developers, testers, Scrum Master, Product Owner, and necessary support roles.
• Combines sprint timeboxes, team capacity, and labor rates to forecast cost per sprint and per release.
• Useful during release planning, budgeting, and ongoing cost tracking.
• Produces metrics such as sprint cost, burn rate, and cost per story point.
• Supports value-based decisions by comparing expected cost with anticipated business value.
• Updated iteratively as velocity, staffing, or rates change.

Purpose of Analysis

People Costs helps the Product Owner and stakeholders understand how much budget is needed to staff the Scrum Team and deliver the prioritized work. It enables transparent cost forecasts for sprints and releases, and provides a baseline to monitor actual spend against plan.

The technique also informs trade-offs in scope, timing, and staffing by exposing the financial impact of capacity changes and schedule shifts.

Method Steps

• Identify roles and team composition, including Scrum Master and Product Owner effort (full or partial).
• Gather labor rates for employees and contractors, including on-costs such as benefits and fees.
• Determine sprint schedule and capacity (working days, holidays, and average availability).
• Estimate effort or throughput (e.g., velocity) to understand likely sprint scope and duration of the release.
• Calculate sprint cost: capacity hours or FTEs multiplied by fully loaded rates for each role.
• Add allowances for training, onboarding, tools, and necessary travel if borne by people budgets.
• Apply contingency or management reserve based on risk exposure and organizational policy.
• Aggregate sprint costs into release forecasts and establish a cost baseline for monitoring.

Inputs Needed

• Team roster and role allocations, including part-time allocations for PO and SM.
• Labor rates or fully loaded cost per role or per FTE.
• Sprint calendar, timebox length, holidays, and expected capacity.
• Historical velocity or effort estimates for epics and user stories.
• Contract terms for vendors or contractors (T&M vs fixed-price).
• Organizational cost policies, benefits multipliers, and overhead rules.
• Risk register items that could affect staffing or duration.

Outputs Produced

• Sprint-level labor cost estimates and expected burn rate.
• Release cost forecast and funding schedule.
• Cost baseline for monitoring and reporting.
• Cost per story point or cost per item (for trend analysis, not for performance comparison across teams).
• Staffing cost report for stakeholders and governance reviews.

Interpretation Tips

• Use cost per story point only as an internal trend indicator; do not compare across different teams.
• Align people cost forecasts with sustainable pace and real capacity, not idealized hours.
• Track actuals per sprint and adjust forecasts in a rolling-wave manner as velocity stabilizes.
• Consider contract model impacts: T&M aligns with capacity forecasts; fixed-price may shift risk and require buffers.
• Separate value discussions from cost: high cost can be acceptable if the expected value is higher.

Example

A team of 7 works in 2-week sprints. Fully loaded daily rates: 5 developers at 500 each, 1 tester at 450, Scrum Master at 550 (50 percent), Product Owner at 600 (30 percent). There are 10 working days and 90 percent capacity.

Estimated sprint cost ≈ (5 × 500 × 10 × 0.9) + (1 × 450 × 10 × 0.9) + (0.5 × 550 × 10 × 0.9) + (0.3 × 600 × 10 × 0.9) = 22,500 + 4,050 + 2,475 + 1,620 = 30,645. Add a 10 percent contingency to get ≈ 33,710 per sprint. Multiply by planned sprints to forecast the release budget.

Pitfalls

• Ignoring non-development time such as ceremonies, backlog refinement, or support work.
• Underestimating PO/SM effort or treating them as free overhead.
• Failing to include benefits, taxes, contractor fees, or location adjustments.
• Locking a fixed estimate too early and not updating after velocity changes.
• Using cost per story point to rank or compare teams, which drives unhealthy behaviors.
• Equating higher cost with lower value without considering business outcomes.

PMP/SCRUM Example Question

During release planning, the Product Owner asks for a forecast of the labor budget for the next four sprints. Which technique should the Scrum Master recommend to estimate this spend using team capacity, rates, and sprint length?

1. Cost of Change.
2. People Costs.
3. Risk Burndown.
4. Definition of Done.

Correct Answer: B — People Costs

Explanation: People Costs estimates labor expenses based on capacity, timeboxes, and rates. The other options do not produce a sprint or release labor budget.