Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are a small group of 5 people that is about to start a new project. This is the first project where we will go all-in on scrum.

We are struggling a bit with how we are going to establish a base for the project (frameworks and the like). Such tasks are not something the user will benifit from directly, so we are having a hard time figuring out how we write user stories for it.

So in general, how do you use scrum, when you are starting a project from scratch, with no frameworks and no base library in place?

share|improve this question
up vote 6 down vote accepted

In various agile methods, there is often a concept of an initial increment (in Scrum, a sprint) that is designed to set up your project. This is often called Increment Zero (or, in Scrum, Sprint 0).

Such an increment is used to set up the team's environment - set up your development, test, and production environments, configure your supporting tools and scripts, and establish your working environments with burndown charts and backlogs. If anyone on the team is not familiar with the development tools being used, this is where they learn the basics to function and begin producing output in the first iteration.

Along side this, you'll often be starting to write your first user stories and prioritizing your product backlog, since there isn't a sprint backlog at this point. Whoever is the Product Owner will be devising stories. If this person is new to Scrum, they would be learning how to write good user stories that the team can work with, as well. Don't emphasize getting all of the stories, but you'll want enough to kick off the first development iteration.

Different teams handle Sprint 0 differently. Some might timebox it at the same duration as any other sprint. Others might make it a little longer or a little shorter depending on the needs of the team. Since this is your first attempt at Scrum, I might make it longer, especially if you have a shorter iterations as part of your development cycle. If you are planning on two week iterations, make it 3 weeks.

As far as formulating the tasks, I wouldn't necessarily formulate them as user stories. You could, from the perspective of team members and various roles (Product Owner, ScrumMaster, developer, tester, designer, technical writer, and so on). However, Sprint 0 is for the team, not for the customer or the user. A simple list of tasks and activities would suffice.

share|improve this answer
Sprint 0 is directly for the team but indirectly benefits the customer as it lays the foundation for sprint work to come. Great answer, you make it sound easy and not as chaotic as Sprint 0 usually feels. – maple_shaft Mar 9 '12 at 16:35
Any project launch is usually chaotic to some extent, depending on the team. Not only are there usually technical issues with getting everything set up, but also personal issues between members of the team and process issues figuring out how to best deal with problems that arise. – Thomas Owens Mar 9 '12 at 17:52

These are the pre-requsites that we established before implementing SCRUM in our team. Once you are done with the list , then you can roll out the process and tools for actual scrum.

  1. Team members are highly or moderately skilled.
  2. Team is tightly knit.
  3. Information exchange among team members is fast, consistent and free flow.
  4. Team is co-located.
  5. Business is highly involved with team.
  6. Architecture ( Business, Information as well Technical) is well defined.
  7. Infrastructure is up and running – Dev, test and UAT environment.
  8. Automated build and release.
  9. High level of test automation.
  10. Team’s dependency on external world is minimum (ideally zero).
  11. Participating systems count is minimal.
  12. Requirements are stable at higher levels so product backlog has minimum changes.
  13. Team members are autonomous to take decision on what user story should be part of sprint/scrum as well as total numbers of scrums/sprint needed to achieve stated goal.

Other two important parts:

  1. Select the people for the roles ( Scrum master, Product owner and the team)
  2. Have your white board ,stickers ready.
share|improve this answer
What do you mean with #11? – Matt Grande Mar 9 '12 at 14:50
In my experience, if the application depends on or inter connected with external systems, SCRUM did not work well . Dependency on other teams reduced the efficiency of our process. May be it was just our project... – java_mouse Mar 9 '12 at 14:59
Oh, okay, so you meant systems that needed modifications. I just thought it was systems that were included, hence the confusion. In the past, we've managed that by having two "levels" of scrum. A lower-level one for each system, and a higher-level one for the whole project to include all the teams. – Matt Grande Mar 9 '12 at 16:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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