Managing deployment and configuration tasks in Scrum [closed]

Question

Just wondering how others out there are managing tasks not directly related to fulfilling user stories such as server configuration and application deployment (in a web application environment). Previously I’ve included these activities within the task breakout of a product backlog item but the effort tends to get lost amongst other tasks directly related to fulfilling the user requirements.

Do others create dedicated product backlog for this sort of work? Or roll it into existing requirements under the guise of “required to be potentially shippable”? Or do you not even include this within a Sprint plan? Interested in different approaches out there. Thanks!

Answer 1

In order for a story to be regarded as "done-done", it needs to be shippable, which includes not just tested but also deployed and configured.

If you have the infrastructure already established then this should be included in your estimates for the story.

If you don't have the infrastructure, then the construction of the build script and deployment system is a story in its own right: except that the "customer" here is a developer or an infrastructure guy, not a developer. So:

As a developer, I need to deploy the XYZ application and verify that it passes its functional tests so that we can regard other stories as complete.

would be a perfectly acceptable story in this context.

Once you have a few of these stories under your belts then you'll know how long they typically take. Estimation of subsequent stories is then much easier.

Answer 2

We have a separate task list for tasks like server administration, and plan our deliverable dates around that. For example, through experience I know that I will spend about 2 hours per day doing administrative tasks, so when I tell my project manager that something will take 4 hours he automatically adds ~2 hours to the deliverable date, and lets the CEO know it will take 6 hours (or 1 work day).

Alternatively, some "administrative" tasks are pre-requisites for getting deliverable projects done. For example, if a project includes re-writing a slow part of our website to be more efficient, and part of the problem is that our servers aren't set up to utilize memcached which we need, then setting up and configuring memcached becomes a pre-requisite project to re-writing the code. The reason it's not rolled together is because when we've set up caching properly, then the intensive part of the site may run well enough that we want to insert another important sales-related project beforehand. This keeps it agile.

I think this is relevant: http://joelonsoftware.com/articles/SetYourPriorities.html - specifically towards the end where he outlines his method for prioritizing features.

This article on evidence-based scheduling also seems relevant: http://joelonsoftware.com/items/2007/10/26.html