How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

People Costs

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.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Build an ICS/OT cybersecurity foundation that fits the real environment

Standard IT controls can disrupt the industrial systems they are meant to protect. Learn how to assess OT risk, design zones and conduits, apply IEC 62443 security levels, use MITRE ATT&CK for ICS, and establish passive asset visibility without risking production. Eight reconstructed incidents connect attacker techniques to the controls that failed, giving you the vocabulary and judgment to make credible security decisions from day one.

Explore the Course