Use Backlog Estimation to Provide Planning Values
In Scrum, teams often perform a first pass through the Product Backlog (generally at the Theme or Epic levels) at the start of a project in order to define project scope and to set initial target dates. While story points, Sprint Goals, and the Product Backlog frequently change over the life of the project, target dates are generally modified less often when used for time-boxing the project's deliverables.
This same first-pass process can be useful in determining resource requirements. While the cone of uncertainty is largest at the start of the project, it is still possible to present an approximation based on documented assumptions.
For example, if you're building a new web application, during your first-pass estimate of the backlog you might identify:
- The need for a database server, a web server, and an email server in each environment.
- The need for three environments: development, quality assurance, and production.
- A requirement for high-availability in production, which the team assumes will be one hot and one standby server per service.
You could take this initial set of assumptions, and present a request for 12 servers based on what the team knows today. You might even present it as a range, representing your level of confidence in the assumptions. For example, you might say something like:
Based on the team's initial assessment of the project requirements, we expect that the project will require a minimum of 12 servers. These assumptions are based on X, Y, and Z with a current confidence interval of approximately 60%. We therefore recommend that the project budget for 18 servers, and that the project assumptions be reviewed quarterly to determine if:
- Resource requirements have changed.
- Planning values remain valid.
By providing transparency in your estimating process, you provide the organization with visibility into the project's assumptions and make it clear that these are estimates that can be revised as the project evolves and the cone of uncertainty narrows, as opposed to fixed guarantees. After all, the ability to inspect-and-adapt is the very hallmark of an agile process, and provides management with the levers they need to manage the project successfully.