Managing deployment and configuration tasks in Scrum

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

I don't understand "lost" in the question. It's work you must do. So how can it be lost?

The "theory" behind Agile is that you have a mature infrastructure.

There are two distinct infrastructure issues.

• Creating new infrastructure.

• Using existing infrastructure.

When creating new infrastructure, we build the exploration into the first few sprints. You can't schedule this. You cannot predict the various paths, roadblocks, pitfalls, snares and traps in this. It requires learning. Don't try to predict the time required to lay down a new infrastructure. Stuff will go wrong. If it doesn't, then the infrastructure isn't really "new" -- it's a clone or copy.

Using existing infrastructure -- Server Config and Deployment -- happens with each release, so we do them as frequently as we can.

Some things (like our new firewall) threw real complexities into some releases.

But generally, Config and Deployment -- like a mature infrastructure -- are foundational. They're already part of your process. You're already doing them. How can they be "lost"?

What do you mean by "effort tends to get lost"? What does "lost" mean? You knew you had to do it. You did it. What's lost?

---

Edit. The idea that this time is "lost" or "not visible" or an "impact" or anything other than business as usual doesn't make any sense, in spite of all the comments.

This is just stuff you do. It's part of the release. It's just work, like development, that you just do.

"A day of migration is a long time" But if that's what it takes, then that's what it takes. You simply allow for it. It's simply a task that you do with every release.

If the schedule is sacred -- and the day of migration is a "problem" -- you have to ask who has the "problem" and what "problem" do they have? Is it a project manager's problem? If so, the schedule has trumped the delivered feature set, and that project manager needs to rethink their view of reality. The user's feature set is real. The schedule is just a nice idea that didn't always work out.

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

Answer 3

We use two approaches. Things like deploying the app are included in user story lifetime. The story is done when it's deployed.

If we have some stand-alone tasks not related with the specific story (e.g. configuration of new testing environment, but changing the architecture also goes to this category) we just add them as another 'story'. I know that's not actually user story but we work on these similarly. Someone has to do job, someone else verifies whether it works fine or not etc.

Answer 4

Anyone can add to the product backlog including developers, but its the product owners decision as to whether the piece of work occurs.

So if you have a new production environment to be built, add it to the product backlog, in the Scrum planning meeting you can explain to your product owner the relative importance, they may decide it should be done now or later. (The same applies to deploying and/or configuring an application)

If you have a refactor task that will improve app speed, add it to the product backlog and again the product owner can decide the relative importance and whether its done now or later.

If you have a refactor task that really has to be done to enable development to continue smoothly then I would guess there is something in the product backlog that this refactor could piggy back on to and the estimates for that backlog item should reflect that.

Answer 5

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.