3

Let's suppose a customer comes to us, explains their needs in business terms and ask us to develop a software solution. The customer agrees to do it by Scrum.

How do we start a Scrum project?

For example:

  • What should be done first and who needs to be involved?
  • Should the product backlog be ready before we start? If the product backlog is not ready before the start, then we can't prioritize it and choose the things to be done first.
  • When do we gather the team?
3
  • Your first bullet point is probably opinion-based.
    – Sarov
    May 12 at 14:58
  • Who is the "us" the customer came to and signed the contract with, if there is no team to do the work?
    – Erik
    May 16 at 13:22
  • @Erik The contract is not signed yet.
    – Daniel
    May 16 at 15:43
7

There are a two things that need to be in place for a Scrum team to start sprinting:

  • The team needs to be assembled
  • They need a prioritised backlog with at least one sprints worth of work in it

The first few sprints will often involve a bit more backlog refinement than a more established team because the team will be trying to create a bit of a buffer in their backlog. There may also be some other activities like the team defining their ways of working, definition of done, etc.

It is also not unusual for the first sprint to have a 'hello world' feature delivery. That is a minor feature is delivered, but many setup tasks are completed (build pipeline, tooling, etc.).

3
  • But how is that prioritised backlog created in the beginning? The customer can't create it because they don't know much about Scrum and backlog management, etc.
    – Daniel
    May 16 at 6:15
  • There are several approaches to creating a new backlog. Story mapping, event storming and domain driven design for example. May 16 at 8:28
  • For a new project's backlog, just writing down whatever was discussed when discussing the original project, broken down into goals and requirements is enough to get a team started.
    – Erik
    May 16 at 14:07
3

In a nutshell: identify a Product Owner and then start with a Sprint Planning meeting.

There are two likely scenarios. Either the Product Owner (PO) or sponsor already has an idea of things they want; if so, document those on a product backlog. Or there is some discussion needed to establish the first things (not everything) that need to be done. A sprint planning meeting on the first day with the whole team, or at least a core team, present should be able to resolve some priority items to work on for the first week or two.

Keep the initial planning meeting and the initial sprint duration as short as possible. It's a common mistake to attempt to plan too much detail from the beginning or to start with sprints being too long. The product backlog can evolve through a process of backlog refinement as you go.

For software projects where you are unsure about sprint duration, I would suggest your initial sprint be no more than one or two weeks at most. Short sprints are much easier to plan than longer ones. The first sprint may not turn out the way you expect - so keep it short so you can "fail fast" if necessary. You can always make sprint 2 longer if you must.

2
  • When do we learn what technology stack we are gonna use? When do we determine what developers we need?
    – Daniel
    May 16 at 6:43
  • 1
    @Daniel If you are providing services to a customer then the likely tech stack at least ought to be discussed before the contract is signed. You said "a customer comes to us ... and ask us to develop a software solution". My assumption was you already had a proposal accepted by the customer. If not and the customer has no preference about technology then that should be a topic at the first sprint planning meeting.
    – nvogel
    May 16 at 9:53
2

Scrum is a framework - inspect and adapt

  1. Hire or assign a Product Owner (PO). One PO can handle 2 or 3 teams. The PO talks to the customer to get a thorough understanding of what is the business problem that needs to be solved.
  2. Hire or assign a senior tech for the dev team. This is a dedicated role for this team. This tech helps select the technologies for the project, sets up the dev environment and helps with selecting dev team members.
  3. Hire or assign a Scrum Master (SM). One SM can handle 2 or 3 teams. The SM sets up the Scrum project management tools, runs the Scrum ceremonies and keeps the team and leadership informed with reports.

For Sprint Planning, the Scrum Guide says you should have one sprint worth of prioritized Product Backlog items (stories) in 'ready' state i.e., fully refined and well understood by the team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

If you take this too literally, you will find yourself in this chicken and egg situation.

At the very beginning of a project I have run a Sprint 0. In this Sprint 0 the Product Owner (PO) outlines the project and business goals to the team. A product backlog is created mostly consisting of epics. The development environment is set up. Definition of Done is discussed among the team and agreed upon. The goal for the first sprint is developed. The backlog is refined to develop one sprint worth of prioritized stories with acceptance criteria and story points.

However, some purists may object to this approach saying that you cannot have a sprint without a shippable increment being delivered. If this is your concern, you can do a minimal 'Hello World' feature delivery as recommended by Barnaby Golden.

But the main point to remember is that Scrum is a lightweight framework. It is not prescriptive. Follow the spirit of Scrum and make practical adaptations as needed and inspect the results in your retrospective meetings.

2
  • But what the team is goona do if they have only epics at the beginning? If we don't even know what technologies we are gonna use, then how do we know what developers we need to hire?
    – Daniel
    May 16 at 6:21
  • Someone in your organization decided to accept this job. Presumably that person should have a high-level idea how to execute. Nevertheless, I have edited my answer with additional info. May 16 at 8:20
1

A Scrum project starts with the first sprint. In order to start the first sprint, you will need a team and a backlog. The backlog is the easy part, most teams can start the first sprint with some random notes scribbled on a napkin if they need to. Assembling the team is usually the hard part unless you already have a team.

Scrum doesn't tell you how to gather a team or obtain your starting backlog. Having them is essentially one of the requirements of doing Scrum. Essentially this is like a recipe; the recipe to bake an apple pie will tell you that you need to have apples. It doesn't tell you where to get them, and it doesn't care if you bought them in a supermarket or picked them from your own tree. The recipe merely requires you to have them, because it deals with how you use the apples and not where you find them.

Scrum is designed as a recipe for turning your team and your backlog into a working product, but getting the ingredients is not part of what Scrum offers. These are business decisions. Scrum is not a guide for how to run your entire business.

Answering your specific questions:

When do we gather the team?

Before you start doing Scrum, because a team is one of the requirements for starting Scrum.

Should the product backlog be ready before we start? If the product backlog is not ready before the start, then we can't prioritize it and choose the things to be done first.

It should be "ready" in the sense that it contains enough information to get started. For many teams, notes from the original meeting with the client is enough to get started. Expanding the backlog will be one of the things taking up time during the first few sprints.

What should be done first and who needs to be involved?

Get the whole team together, grab the backlog and start the first sprint with a sprint planning meeting.

I'll also add in some of your questions from comments, since the answers to those mostly align with what I stated above.

When do we learn what technology stack we are gonna use?

At the very latest, during the very first sprint meeting, when the team decides on how they're going to turn backlog items into a working product. Practically, this is often decided beforehand. It could be the company ("We're a Java software company, so your tool is Java") or the customer ("I need this app that works for all my employees and we give all of them Android devices") But if neither of those have a strong opinion, the team will decide based on what they think the best way to tackle the backlog is.

When do we determine what developers we need?

Before you start doing Scrum, because the developers are part of the team and the team is needed to start Scrum. Determining which developers you want to get into your team is a business decision and Scrum will offer no real help. (Beyond stating that whomever you hire, the whole group needs to have all the skills to handle the project. Knowing when they do is tricky before you start, but it's more a general "three developers who can't design an interface is not a complete scrum team" rule)

But what the team is gonna do if they have only epics at the beginning?

Decompose the backlog into smaller stories and then work on those.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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