What's a good way for a Scrum team to handle budgets and work with other departments?

Question

In my organization, the developers are using Scrum (which started recently), but the sysadmins are not.

We're about to start a large project, and we've been asked for detailed description of our hardware needs so it can be added to the budget, and because the sysadmins have a long queue of work so we'd need to request a new server far in advance, if we need one. The person the heads of both departments report to is not fully on board with the process, seeming to prefer waterfall, so I may need to be delicate in my suggestions.

Can anyone suggest a better or at least more-consistent-with-Scrum way of handling this, other than just guessing what we'll need and hoping it doesn't change?

Answer 1

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:

1. The need for a database server, a web server, and an email server in each environment.
2. The need for three environments: development, quality assurance, and production.
3. 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.

Answer 2

Scrum focuses on development work delivered over a set interval (i.e iteration or sprint).

If the scrum team is not physically setting up the hardware, the scrum framework doesn't apply to your situation.

For agile-scrum projects, there are high level planning requirements which include creating a product roadmap. This roadmap should outline the progression of epics or features and provide sufficient detail to estimate when additional hardware resources need to be ramped up.

Hardware usually consists of two budgeting components; fixed, re-occuring expense for maintenance/support of the hardware plus a one time purchase or configuration fee. It really depends if your project uses cloud/VM/physical "servers", but these costs can be easily budgeted for at the onset of any waterfall or Agile type project.

The re-occuring and one time costs for an Agile-Scrum project can all be derived from the product roadmap and the System Admin managers needs not hear a mention of the words Agile, Scrum, Waterfall, etc.

Keep in mind budgeting is an estimation exercise. Whether your project is waterfall or scrum, most budgets contain a % hedge for uncertainty.