In Scrum, should tasks such as development environment set-up and capability development be managed as subtasks within actual user stories?

Question

Sometimes in projects we need to spend time on tasks such as:

1. exploring alternate frameworks and tools
2. learning the framework and tools selected for the project
3. setting up the servers and project infrastructure (version control, build environments, databases, etc)

If we are using User Stories, where should all this work go?

One option is to make them all part of first user story (e.g. make the homepage for application). Another option is to do a spike for these tasks. A third option is to make task part of an Issue/Impediment (e.g. development environment not selected yet) rather than a user Story.

Answer 1

We thought about this problem quite a lot in the past year.

While I agree that a basic framework should exist before the project starts, in practical use it can be part of the project itself. So you have to manage somehow.

While mixing project setup with user stories might make sense sometimes we have settled on simple tasks that can be added to the product backlog and get the same attention as user stories. We know that these technical tasks are necessary sometimes, but they have to be justified in any case. If the team thinks that they are absolutely necessary to achieve a certain goal, they will be part of a sprint.

It's hard to say what works best for you, so experiment! A spike might suffice for now, but I think you'll end up with the same problem later, so plan ahead. Do tasks that are a placeholder for such activities. To separate tasks from stories two I will quickly compare them based on my experience with them.

Task: A task is a technical necessity. It might be things for configuration management or general project setup, like setting up a repository for commits, or adding the hottest code review tool you have ever seen to the development process. Tasks should be considered in planning, same as a user story. If the team can convince the product owner that having the latest and greatest code review tool increases performance and ups team communication by eliminating long lasting pair programming sessions or in-person code reviews, then it will get the product owner's attention.

Stories: Focused on business perspective only, stories always produce visible value to the customer. Internal quality is something that goes along with producing business value.

We even assign story points to tasks and sometimes work with them the same we would do with stories.

In the end I would go for this solution in your case (which could be applied in general as well):

1. Separate "setup" and technical stuff into tasks (stuff that does not directly produce business value for the product owner).
2. Maybe do a spike prior to project setup to get the most important tools into place (SCM, dev tools, process defintion, coding standards etc.)
3. Accept that these tasks pop up over the duration of the project and plan for this by having a separate "type" of activities other than stories.

Answer 2

Do whatever makes most sense in your company. Don't ever let how other people do things be a hindrance to common sense.

But I will say that all of these tasks sound like something that should happen long before you start development. So I question whether Scrum is even relevant to these tasks. There is some ongoing maintenance and such to source control and databases, but these shouldn't be scheduled, they should just be things that happen and effect your velocity.

There will be times when you have to select a framework or whatever during a project, but when I say that I mean a framework like nHibernate, not a framework like .NET. In those cases, research should be spiked and timeboxed, not to mention fairly short. Try to manage it as if you had a developer off sick for a couple of days.

Knowledge transfer is another ongoing process which should be managed outside of the general development velocity.

Answer 3

There's a name for making as many design decisions as possible up front before the "official" start of your project. It's called waterfall. There's nothing wrong with user stories like, "As a developer, I need to select a framework, so we have a starting point for the web site." If that's too big to fit in an iteration, try breaking it down like, "As a developer, I need to implement a basic home page in Drupal, so we will know if it fits our needs."

Answer 4

One option is to make them all part of first user story e.g. make the homepage for application.

Breaks "user story" as a concept. What user is involved in this? None. This is work you should already have done.

Another option is to do a spike for this.

Not bad.

Third option is to make task part of an Issue (e.g. Development environment not selected yet) rather than a user Story.

About the same as a spike as far as planning and overheads are concerned.

Setup is not a user story.

It's what you should have in place before you even started this project.

You can't really start the project unless you have the framework/tool and servers setup and ready to go.

I'm well aware that many organizations don't really exist until after the contract is signed. I'm also well aware that many organizations don't choose a technology until after the contract is signed. These are all inefficient things that are outside any user stories.

Answer 5

At work we use a task for preparing the environment. It might be confusing for some people but the task we use is very much the same task as the task from a user story. The task does not belong to a user story but is estimated in hours and it has to be agreed on by the product owner to complete in a particular sprint.

We also use the task for architectural work that does not have an "apparent" business value but that adds quality to the product particularly for an existing product with a large code base.

These might not apply in your work environment but it worked well for us.

Answer 6

I think you are mixing two independent things. An user story shouldn't include any technical details.

The choice of framework, setting up repositories and servers, and other tasks, should go into the initial iteration.

Answer 7

I went on a Scrum course recently and the instructor suggested that a special sprint called Sprint 0 should be used to solve exactly these sorts of problems. There were people on the course with varying degrees of experience in Scrum and pretty much all of the experienced people agreed, saying that they did the same thing. In some cases, the companies used Sprint 0 to evaluate the project and decided if it was feasible or not.

To someone new to the Scrum methodology like myself, it seems like a fantastic solution because it keeps you free from user stories and all of the other aspects of a normal sprint such as user feedback.

As Sprint 0 is the same length of time as your other sprints, it acts as a way of ensuring you don't spend too much time getting things set up because they can always be tweaked later. The main point is to get yourself into a state where you can actually start developing the product.

Answer 8

on exploring 2-3 alternate framework/tool

Sometimes this can happen if you have special requirement you have to do some POC to choose the best tool to solve the requirement. This is what spike is for because without knowing which framework you will use you most probably cannot estimate the story and store without estimate cannot be planned and divided into tasks.

then on learning the framework we select for the project

Well. This is quite dangerous. When customer pays you for a SW he expects that you are professional who already know how to use his tools. Customer doesn't pay you for learning or trial / fail development approach. It is developer responsibility to learn new tools in his free time or in special allocated time paid by his employee not by customer. Spending customer money for learning without informing customer is unprofessional.

If you really have to use something special (for example some customer's API or tool customer selected) which you never used before you must inform customer that price will be increased by time needed to learn how to use the API. Maybe customer will change his mind if the price increase will be too big.

Sure, I don't mean situation where you must look for some particular new problem in framework you have used many times. I mean the situation where you start using new API or framework without spending some significant time (outside of the project) for learning.

If you violate this it will be visible in your velocity anyway because you will deliver very small amount of business value per iteration. If customer is not aware of the reason he will most probably cancel the project.

This is still valid in case of internal projects - you must inform your manager / business about time needed for learning new API or tool. It has usually very bad consequences if manager counts with your normal productivity and your productivity is only fraction because of new API you are trying to learn during your tasks. That is obviously even worse if some sale people calculated with normal productivity when signed contract with the customer.

on setting up the servers (SVN, Databases, etc)

That are your infrastructure and internal costs. When you start the project it is expected that you have your infrastructure prepared. Setting up your development environment has no value for customer and should not be part of any project related indicators - for example velocity in Scrum. I saw this implemented as special pre-project iteration used just to setup environment, create basic infrastructure etc.