HKSM

A technique that converts expected resource usage into monetary cost to plan and control spend in Scrum projects. It uses team capacity, duration, and rate cards to estimate cost per sprint and release. It complements effort estimates by translating velocity and resource needs into a budget.

Key Points

• Tool to calculate the cost of people and non-people resources for sprints and releases.
• Combines usage quantities or time with internal or vendor rate cards to derive cost.
• Used in release planning, budgeting, and ongoing cost control in SBOK contexts.
• Covers labor, tools, environments, licenses, training, and outsourced services.
• Produces a time-phased cost baseline and team burn rate per sprint.
• Updated iteratively as velocity, capacity, or procurement assumptions change.

Purpose of Analysis

Resource costing enables the Product Owner and stakeholders to understand how much funding is needed to reach an MVP or release goal. It informs business justification, funding approvals, vendor agreements, and prioritization by connecting effort to actual spend over time.

It also supports economic decisions such as build vs. buy, fixed-price vs. time-and-materials, and the affordability of product roadmap options.

Method Steps

1. Define the scope window for costing: upcoming sprint, MVP, or release.
2. List resources required: Scrum Team roles, shared services (UX, DevOps), tools, test environments, licenses, and any vendors.
3. Quantify usage: team capacity per sprint, expected number of sprints, planned FTE mix, and one-time vs. recurring non-labor needs.
4. Collect rate cards: internal fully-loaded rates and external supplier rates; include overheads if applicable.
5. Compute base cost: multiply quantities or duration by rates for each resource; sum by sprint and by release.
6. Add reserves: apply contingency based on risk exposure and known uncertainties.
7. Time-phase the totals: create a per-sprint cost baseline and team burn rate.
8. Review and refine: validate with team and suppliers; adjust for holidays, ramp-up, and learning curves as empirical data emerges.

Inputs Needed

• Release goals, MVP definition, and product backlog scope candidates.
• Forecast velocity and expected number of sprints to reach goals.
• Team composition, availability, and capacity per sprint.
• Internal rate cards and external vendor quotes or contracts.
• Non-labor cost estimates: licenses, cloud infrastructure, tools, training, environments.
• Risk register and contingency approach for reserves.
• Sprint calendar, holidays, and ramp-up or onboarding assumptions.

Outputs Produced

• Time-phased cost baseline per sprint and aggregated release budget.
• Team burn rate and cost per sprint for financial tracking.
• Cost of MVP and alternative release scenarios with ranges.
• Budget request or funding plan, including contingency and management reserves.
• Optional cost-per-story-point metric for internal trending only.
• Supplier cost breakdown supporting procurement decisions.

Interpretation Tips

• Use ranges early; narrow them after a few sprints when velocity stabilizes.
• Rebaseline after major changes in team capacity, scope, or vendor terms.
• Do not compare cost per story point across teams; use it only for trend analysis within the same team.
• Allocate shared services and platform costs transparently to avoid double counting.
• Link cost to expected value delivery so prioritization considers both economics and customer outcomes.

Example

A Scrum Team plans an MVP in 5 sprints. The team burn rate is estimated at USD 45,000 per sprint (7 people at an average fully-loaded rate), plus non-labor costs of USD 8,000 for licenses and USD 5,000 one-time for UAT environments.

Base labor cost: 5 sprints x 45,000 = 225,000. Non-labor: 8,000 + 5,000 = 13,000. Subtotal = 238,000. Add 10% contingency for known risks: 23,800. Estimated MVP budget = 261,800, time-phased at 45,000 per sprint plus the one-time non-labor items.

Pitfalls

• Treating story points as hours and forcing a direct conversion.
• Omitting non-labor items like environments, security testing, or training.
• Ignoring risk reserves, leading to chronic underfunding.
• Assuming constant capacity and velocity despite onboarding, holidays, or context switching.
• Over-precision early in the project, creating false confidence in a single number.
• Failing to update the budget after changes in scope or vendor rates.

PMP/SCRUM Example Question

While preparing a release plan, a Product Owner wants to estimate the budget using resource costing. Which input is most essential to produce a realistic per-sprint cost?

1. High-level product roadmap themes without velocity.
2. Team velocity forecast and applicable internal and vendor rate cards.
3. Detailed task hours for all sprints before work starts.
4. Stakeholder risk tolerance statements only.

Correct Answer: B — Team velocity forecast and applicable internal and vendor rate cards.

Explanation: Resource costing multiplies expected usage or duration by rates to derive cost. Velocity and rate cards provide the necessary quantities and prices to estimate per-sprint spend.