1

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?

5

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.

  • Great answer. Thank you. The sentence make it clear that these are estimates that can be revised as the project evolves is really the heart of the question I meant to be asking. It's the part I don't expect will be received well. Do you have any advice for that? – Ivy Fae Nov 18 '14 at 21:42
  • 1
    @Ivy Honesty and transparency help a lot. If you've clearly articulated the assumptions that underlie the planning values, you've done your job. However, you can't control whether other people will be happy about the planning values; that's under their control, not yours. – Todd A. Jacobs Nov 18 '14 at 21:51
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.