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.

  • i have changed question a bit to make it more clearer.. question has now as subtasks within actual user stories instead of as stories Commented Feb 13, 2012 at 4:40

8 Answers 8


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.
  • So what you are calling TASK is basically a work item like User story or Bug?.. It is not the TASK as in the tasks within user stories e.g. code, test, deploy etc. Commented Feb 12, 2012 at 19:07
  • 2
    Yes to get the distinction between those we call sub-tasks of stories "Activities".
    – malte
    Commented Feb 12, 2012 at 19:08
  • What you call Task is then basically an Issue as per MSF for Agile 5.0 Commented Feb 12, 2012 at 19:27
  • If you refer to this description here: msdn.microsoft.com/en-us/library/dd997897.aspx - You could call it an issue as it was described there, that would be fitting I think. So that would make it your option number 3.
    – malte
    Commented Feb 12, 2012 at 19:50
  • 2
    Point 3 "Accept that these tasks pop up over the duration of the project" is especially important. The Agile Unified Process has a great picture that demonstrates this: i.sstatic.net/CUVFI.jpg. Notice that they "environment" discipline never really disappears. Also notice that the bulk of the environment work is up front. So if you suddenly find that you're doing lots of environment work in a later phase there may be something going wrong.
    – Michael
    Commented Feb 12, 2012 at 23:14

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.

  • when i said framework.. it was like should we go for JSF or Spring.. or when i said tool.. it was like should we go for Jboss or Glassfish.. Commented Feb 12, 2012 at 18:04
  • 1
    I don;t know what you mean "long before you start development".. when project starts, shouldn't sprint 1 start ASAP e.g within 2 weeks of project start date... and in sprint 1 there is real coding. Commented Feb 12, 2012 at 18:06
  • 1
    @AsimGhaffar: I don't think it should, no. If you start coding before you've even made decisions like which application server to use, you are going to make at least one decision that requires you to rewrite most of that code. And I can't imagine starting a project nowadays without source control set up. I mean ok, if you have developers sitting around, find them something productive to do, like prototypes. But don't go headlong into the project until you've made the key decisions.
    – pdr
    Commented Feb 12, 2012 at 18:18
  • "shouldn't sprint 1 start ASAP e.g within 2 weeks of project start date". Correct. That means your environment is all set up and ready to go. You are already skilled in using the tools, doing builds and deployments. If you're not already skilled in these things and the environment is not setup, then you're not ready to start.
    – S.Lott
    Commented Feb 12, 2012 at 18:21
  • @S.Lott hmm I thought that one gets required skills ON THE JOB i.e. while working on project and there is no learning-tool prerequisite for sprint 1. Commented Feb 12, 2012 at 18:46

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."


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.

  • issue is not same as Spike.. Think of issue as work item scheduled in normal sprint but doesn't have story points.. Example of Issue: SVN is not selected. I am borrowing the word issue from MSF for Agile 5.0 Commented Feb 12, 2012 at 19:24
  • "issue is not same a spike". For the definitions of the words, you are correct. But when you think about planning extra work before sprint 1, it does not matter if you call it an issue or a spike. Pick one. Toss a coin. Heads.
    – S.Lott
    Commented Feb 12, 2012 at 19:28
  • Again I meant scheduling issue alongside stories within Sprint 1 - not before Sprint 1. So for Sprint 1 lets say we pick 2 user stories and 1 issue. No story points for Issue though. Spike indeed will be before sprint 1.. Commented Feb 13, 2012 at 4:28
  • Spike or Issue does not matter. It's all work that is not part of a user story. It's all work that must be done before the first sprint. You can call it a spike or an issue, whatever makes you happy. But it is not a user story.
    – S.Lott
    Commented Feb 13, 2012 at 10:48

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.


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.

  • you are right and i am not suggesting to have them in the story description.. what i meant was to have tasks such as "install MySQL", "evaluate framework" as part of first actual user story.. i.e. As a user I want a homepage so that I have a quick access to essential features. Commented Feb 13, 2012 at 4:26
  • @AsimGhaffar That can be done in the initial iteration. Not as a user story, since users do not need to know (nor they should care) what technology you used to satisfy their needs. Commented Feb 13, 2012 at 16:30

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.

  • 3
    Quoting Alistair Cockburn I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented "Oh, that was Sprint Zero!" to get the peasants with the pickaxes away from his doorstep. Commented Feb 13, 2012 at 4:44

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.

  • We are into product development not customer projects :). Commented Feb 13, 2012 at 14:18
  • Ok. In such case you should still separately track time spend on learning and infrastructure to see what overhead you have. Hiding this time inside tasks will corrupt visibility of your development process. Commented Feb 13, 2012 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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