What is prerequisite for starting a Sprint?

Question

What are the mandatory prerequisites to start a Sprint?

The Product Owner makes decision to start the Sprint; what are the Scrum Master's/Development Team's roles in making the decision?

Does the Scrum Master just coach in general terms for this decision or does s/he have to provide specific guidance?

Answer 1

It depends on what you consider "mandatory prerequisites to start a Sprint".

When it comes to the timing of the start of a Sprint, the Scrum Guide says that:

A new Sprint starts immediately after the conclusion of the previous Sprint.

There is no decision to start the Sprint. One Sprint ends with the Sprint Review and Sprint Retrospective and the next Sprint starts with Sprint Planning.

However, if you dig deeper, you can find some implications for how to be ready for the start of a Sprint:

• You have a Product Backlog with items in it. If there is nothing to work on, there's no need to have a Sprint.
• Your Product Backlog is ordered. One of the functions of the Product Owner is to remain accountable for "ordering the items in the Product Backlog to best achieve goals and missions". The Product Owner can con
• You allocated some time in previous Sprints to perform refinement of the Product Backlog. The Scrum Guide suggests 10% of the Development Team's capacity, but this is not a timebox. This helps you to ensure that the top of the Product Backlog is well understood.
• If this is not your first Sprint, you've held a Sprint Review and Sprint Retrospective and have updated your Product Backlog based on feedback received.

Minimally, going into Sprint Planning, you have an ordered Product Backlog. Ideally, you have a Product Backlog where the top items are refined and well-understood by the team. This enables you to effectively start a Sprint.

Answer 2

Work in Scrum is performed in Sprints, with one Sprint starting after the previous Sprint has ended. For each Sprint you have a Goal, which is the thing you want to achieve or accomplish during that Sprint. Basically, a Sprint is like a mini project that adds some functionality on top of what you have already built so far.

So now the question becomes "what do you need to build that mini project?" You need some requirements. You need some estimates to know if you can actually fit the work in one Sprint without the work spilling over beyond the Sprint duration. You need a plan to do the work. You need to identify dependencies and potential risks. Then you can start the actual work (the work is the most important part because that's what creates you next product increment).

Those things I just mentioned are what you need to start the work in the Sprint. Some of them you need to have before the Sprint begins, some of them will happen once the Sprint starts.

For example, planning the work for the Sprint is done during the Sprint (the Sprint starts with a Sprint Planning meeting). During the Sprint Planning meeting developers also estimate the work. Also during planning, dependencies, risks, and assumptions are discussed and decisions are taken on how to deal with them. So from what I said above it seems only requirements (which will be in the form of Product Backlog items, usually User Stories) are the prerequisites, right?

Not really. There is more than that.

What happens at Sprint Planning is to plan the work for this Sprint. So the prerequisites are all the things needed to do that sucesfully:

• the obvious ones are the requirements (I'll refer to them as User Stories from now on). The User Stories need to be properly defined before you can work on them. So a prerequisite for the Sprint is to properly do Refinement before the Sprint, so people know what needs to be built with each User Story.
• speaking of Refinement, the Product Backlog needs to be properly ordered so when the Sprint starts you know what to focus on (i.e. the items at the top of the Backlog). This is a prerequisite, to have the Backlog properly organized.
• you estimate at the Sprint Planning the items you will work on during the Sprint, but you already need to have a rough idea about them before you provide a finer estimate. This is again related to Refinement. The User Stories need to be estimated during Refinement so you have a rough idea of what effort will be needed. During the Sprint Planning you clarify that further.
• Scrum teams needs to have all the skills necessary to create a product increment, but sometimes reality just doesn't care. You might depend on some external resources, vendors, etc. You need to have the dependencies already resolved before you start a new Sprint otherwise you take on risk. That means that you still need to do some overall planning before hand, to make sure you don't go into the Sprint with assumptions that might later not materialize. Discussing these at the Sprint Planning would be too late, you need to have them sorted out by the time you start the Sprint
• at the end of the previous Sprint you had a Retrospective meeting. Did you decide on any Action items you need to take? Are those actions needed this Sprint? What do they entail? These are another example of prerequisites.
• during the previous Review Meeting did you collect some feedback that changes priorities for the next Sprint? You have to incorporate them in the Backlog before discussing user stories at the Sprint Planning.

These are just a few examples of the top of my head. There might be more. Like I said, a Sprint is like a mini project. Prerequisites are everything you need before starting the work on the mini project and building something useful out of it. Prerequisites will vary from product to product, and Sprint to Sprint. If I were to chose one, it would be to have a properly ordered and refined Backlog.

The Scrum Master can offer guidance to make sure you nobody jumps head first into a new Sprint, but with proper Scrum, everyone (development team + Product Owner + Scrum Master) needs to have a view of what was done, what needs to be done next, and what's needed to do it.

Answer 3

The Scrum Guide says nothing about the prerequisites for starting a sprint, although you can infer that at the very least a Sprint Goal is required.

Its not an official Scrum Guide thing, but I have often heard it said that a sprint should not start without sufficient work items on the Product Backlog to fill it with. In other words you shouldn't be preparing backlog items during the same sprint you are planning to work on them.

Even this is not a hard-and-fast rule though, as I have seen teams take items into a sprint they know still need some preparation work. However this has always been treated as an exception rather than part of an approach.

The Scrum Master definitely is not the one making the decision about starting a sprint, although as you say they may provide guidance.

The Product Owner is also not the definitive decision maker as they are jointly responsible for the sprint with the development team.

I would say that the answer to who has the final decision about starting a sprint, as with most things in Scrum, is ask the team. It is a collaborative decision made by the entire Scrum Team.