How does a Scrum team account for infrastructure tasks in the planning meeting?

Question

How does a Scrum team account for dev/infrastructure tasks in the planning meeting?

At first glance, they do not seem like user stories since they do not deliver end user value.

However, attaching them as tasks to a particular user story sometimes does not make sense either. For example, say the task is: "Setup Bamboo." That task is not required to complete any user story since the team could manually build and deploy. So attaching it to a user story does not make sense since this task is not required to complete the user story.

So, then, this suggests that these tasks become user stories. But then, if the team story points them, then this changes the velocity which is odd since the Product Owner wants to know the velocity against his backlog, not against his backlog with a bunch of technical user stories attached to it.

Answer 1

They're not actually user stories. They're stakeholder stories. Unless the software is actually paid for direct by users, it's rare that a story is created entirely for their benefit.

I give you a couple of examples:

• keyworded articles, which allow advertisers to have more effective adverts
• CAPTCHAs, which are there to stop moderators having to deal with spam manually.

Most technical stories actually provide a business benefit, but it's rarely for the users. Phrasing them in a different way can help. I normally use Chris Matts' Feature Injection template:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

This explicitly recognises all kinds of stakeholders, including the development team. Now you can phrase your technical stories too, calling out the business benefit:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

I've written a couple of blog posts on this: They're not User Stories, and Feature Injection and handling technical stories. Hope they help.

Answer 2

Velocity is a measure of the team's capacity to do useful work (as opposed to Drag). Infrastructure tasks still deliver end-user value, albeit indirectly, by making the team more efficient in the long run. I have no problem tracking these things as user stories (the user is the dev team in this case) and prioritizing them appropriately. A Product Owner in good communication with the customer(s) should be able to figure out where such tasks can fit without disrupting deliverables.

Answer 3

Do them gradually.

If no stakeholder wants it, don't make it a story. Just take care of it, a bit at a time. E.g., the first time you deploy manually. The second time, you automate a bit of it. The third time, you automate a bit more. Eventually, your build is not the biggest problem, so you focus on something else.

You will have more of these developer-focused tasks at the beginning, and that's fine; your velocity (as measured by stories) will just be lower. That's a correct representation of the situation. But you will always have some, so it's important for the team to get in the habit of doing what's necessary to improve the process.

Answer 4

IMHO the ideal approach is placing infrastructure effort as tasks under the user story where it first holds value; as you have mentioned.

Taking your example; manually building and deploying implies it is an ongoing effort and has no form of completion. It exists indefinitely.

The same could be said for code which automates any portion of effort in a typical application which was previously done manually. Defining this effort as a task under a user story defines complete; which by its very nature has value to the end user.

You could certainly build and deploy the application each and every sprint but that then becomes part of the day to day tasks which are not formally tracked via the backlog and then this all becomes moot.

Answer 5

User stories define a buisness value from the user perspective. Because of that infrastructure tasks are generally considered as a "waste". It doesn't mean they are not need. It means that doing more infrastructure tasks will deliver less business value. Because of that infrastructure tasks should not be considered as a user storie and should not be attached to any user stories.

On a planning meeting team must consider what infrasturcture tasks will be absolutely necessary during the next sprint. The commitment will be done with these infrastructure tasks in mind. It will affect team's velocity which is correct result because velocity measures how much business value the team can deliver.

Answer 6

From what I have seen much of the infrastructure is considered a given. This includes things like:

• Revision control system;
• Automated build system;
• IDE and other developer tools;
• Development servers;
• Deployment process; and
• Project process and standards.

Most methodologies I have worked with don't give much attention to them. These form what I call Release 0. These things should be in place before you begin development. Once you start working on the stories any changes in these things could be tracked as process improvements.

While the development team may have input, most of these items should be handled by a project support team. Standardizing these items across multiple projects should have a significant payback for the organization.

Answer 7

I never equated user stories to having to deliver end user value. It may be common, but its not how we handle user stories. Sometimes, these types of tasks are considered spikes, but we've also had regular user stories, point estimated like any other user story.

Answer 8

Consider the following:

• Scrum team adding major features to an existing product suite.

• There is a need to upgrade development technology/tools/utilities to stay current based upon engineering best practices.

• It makes sense to front load a release with this work so that over the course of the release Sprints issues can be resolved.

• Since the business obtains indirect value from these items I suggest that in the interest of transparency these are Product Backlog Items (PBIs).

• The team sizes these items and treats them as they would any PBI.

This issue for me boils down to the fact that I don't want to waste time trying to figure out how to hide this work as tasks beneath other more business centered PBIs.

I don't want PBI sizing skewed by this sort of infrastructure work. I want to see what is being done and understand what I'm paying for.

I also think there is value in having the team understand the commitment the business is making by investing in the infrastructure required to deliver quality solutions.

Answer 9

XP recommends suggests having an "iteration zero" where all the tools and infrastructure are set up. Writing stories for these is optional, but is probably a good idea. Being able to test your infrastructure (incremental build, automated test and deploy, notifications, etc.) is beneficial

Answer 10

In our team we do the following:

1. Assume a lower focus factor.
2. Try to include such tasks into user stories that actually need implementing them.
3. If some tasks are totally necessary, but provide no direct business value (such as migrating unit tests from one framework to another), at the beginning of the sprint we create a list of "continuous tasks". These are development-related tasks that are not stories, but the development team wants them done. We list these tasks on our blackboard, still keeping it separate from stories. During the sprint, at each daily meeting we review what's been done to accomplish them.

The step 2 is the most important. As in an agile practice, in Scrum you try to do as few as possible to accomplish your tasks. Take it as a way to not waste your life on doing unnecessary work: my experience shows that as much as 50% of "would-be-cool" things end-up abandoned and unmaintained in the long run.