HKSM

The project budget is the approved funding limit for a Scrum project, expressed as a cost baseline and reserves across releases and sprints. It is created early from the business case and high-level estimates, then refined as epics and user stories are sized. It guides prioritization, release planning, and cost control throughout the project.

Key Points

• Represents the authorized funding ceiling and baseline for the project.
• Typically created during Initiate and used as an input to Create Prioritized Product Backlog and Conduct Release Planning.
• Owned and maintained by the Product Owner with sponsor and finance support.
• Expressed by release and sprint, including contingency and, when applicable, management reserve.
• Closely linked to velocity, sprint cost, and value delivery measures for ongoing affordability checks.
• Updated through formal change management when scope, risk, or constraints shift.

Purpose

The project budget provides clear financial guardrails so the Scrum Team can maximize value within constraints. It aligns funding with expected benefits, informs release goals, and helps stakeholders make transparent trade-off decisions.

It also supports governance by defining how much can be spent, when, and on what, while still allowing adaptive reordering of the product backlog to meet changing priorities.

Key Terms & Clauses

• Funding ceiling: The approved not-to-exceed amount for the project or release.
• Cost baseline: Time-phased spending plan by release and sprint, excluding management reserve.
• Sprint cost (burn rate): Total cost per sprint based on team composition, rates, and overhead.
• Contingency reserve: Budget set aside for known-unknown risks, managed by the Product Owner.
• Management reserve: Additional buffer for unknown-unknowns, typically controlled by the sponsor.
• Cost of delay: Economic impact of deferring an item, used for backlog ordering within budget limits.
• Release allocation: Portion of the budget earmarked for a specific release or increment.

How to Develop/Evaluate

1. Gather inputs: business case, epics, constraints, initial risk profile, and any portfolio funding limits.
2. High-level sizing: T-shirt size or story-point epics to estimate total effort and releases needed.
3. Derive sprint cost: determine team roles, rates, vendor fees, environments, and overhead per sprint.
4. Parametric estimate: sprints required = total points ÷ expected velocity; budget = sprints × sprint cost.
5. Add reserves: apply contingency based on risk analysis; define any management reserve per governance.
6. Time-phase the baseline: distribute spend across releases and sprints; include one-time setup and tooling.
7. Validate: compare to analogous projects, run scenario ranges, and check affordability against the business case.
8. Approve and publish: obtain sponsor approval, record assumptions, and share as an information radiator.

How to Use

• Create Prioritized Product Backlog: order items by value, cost, and cost of delay to fit within budget constraints.
• Conduct Release Planning: select target scope and number of sprints per release that the budget can support.
• Estimate User Stories and Commit User Stories: verify that forecasted sprint costs align with the baseline.
• Track during sprints: use budget burnup and release burndown to detect variances early and trigger discussions.
• Adapt with the Product Owner: re-prioritize scope, split stories, or negotiate funding when forecasts exceed limits.
• Governance and procurement: align vendor contracts, tooling, and licensing to the release allocations.

Example Snippet

A team of 7 has an all-in sprint cost of 18,000 and an expected velocity of 40 points. The initial backlog totals 320 points, so the forecast is 8 sprints.

Base cost: 8 × 18,000 = 144,000. Contingency at 15% = 21,600. Total planned budget = 165,600, split across two releases of 4 sprints each.

If actual velocity trends at 35, the forecast becomes ~9.14 sprints. Options include removing lower-value stories, adding funding, or redistributing scope to protect the budget.

Risks & Tips

• Risk: Over-precision early on can mislead decisions; use ranges and refine as you learn.
• Risk: Ignoring non-development costs (environments, data, compliance) can cause overruns.
• Risk: Cutting quality to save budget increases total cost later; maintain the Definition of Done.
• Tip: Keep contingency separate and visible; consume it only when risks materialize.
• Tip: Re-forecast after each sprint using actual velocity and latest backlog scope.
• Tip: Use budget burnup with value delivered to show stakeholders the cost-to-value trajectory.

PMP/SCRUM Example Question

Midway through a release, actual velocity is lower than planned and forecasts show the project will exceed the approved budget. What should the Scrum Master facilitate first?

1. Ask the team to work overtime to recover schedule without increasing cost.
2. Relax the Definition of Done to finish stories faster.
3. Partner with the Product Owner to re-prioritize the backlog and adjust scope or seek sponsor approval for more funding.
4. Wait until the next retrospective to decide on corrective actions.

Correct Answer: C — Partner with the Product Owner to re-prioritize the backlog and adjust scope or seek sponsor approval for more funding.

Explanation: Budget is a constraint managed through backlog ordering and release planning. The Scrum Team should adapt scope or escalate for funding, not compromise quality or sustainable pace.