11

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?

Improve this question

2 Answers 2

Reset to default
7

I don't think that a lot of of agile methods handle the activities that are typically part of project inception well. Many of the common frameworks (XP, Scrum, Kanban) don't address this concern, but some of the scaled frameworks (Disciplined Agile Delivery, SAFe) do to some extent.

Some people advocate for 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). However, it's not a formal part of Scrum and purists say that the first Increment should be potentially releasable.

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.

Improve this answer
3
  • 3
    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. Commented Mar 9, 2012 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. Commented Mar 9, 2012 at 17:52
  • Another tool in the Scrum toolbelt is a series of "spikes" (research stories) where the outcome is essentially determining what options are available and what the team has chosen as it's preferred solution. I.e. when there are no frameworks used, you can have a sprint to determine which (if any) frameworks would help you get closer to a useful product. No framework is always an option, particularly for small one-off utilities. Commented Nov 16, 2017 at 14:35
1

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.
Improve this answer
3
  • What do you mean with #11? Commented Mar 9, 2012 at 14:50
  • 3
    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... Commented Mar 9, 2012 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. Commented Mar 9, 2012 at 16:25

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.