In Scrum, each sprint starts with the planning meeting 1. This very important meeting lays the foundation stone for the whole sprint. Within this article I want to give you an overview about the planning meeting 1 goals and execution steps.

 
General conditions

Participants: Product Owner, Development Team, Scrum Master, User

Moderator: Scrum Master

Content: What do we want to implement within the next sprint?

Duration: 60 minutes per sprint week

Time: At the beginning of each sprint

 
Goals 

Selection of the features from the backlog to be implemented in the sprint

Clear definition and understanding of all feature requirements

Define acceptance criteria’s

 
Meeting protocol

The results of the meeting have high impact on the implementation of the requirements. Decisions made in this meeting will influence the project success. Therefore it is very important to create an according meeting protocol. The moderator (scrum master) will write this protocol and send it to all participants. Furthermore every participants should make his private notes because the scrum master cannot write down every details in the meeting protocol.

 
Execution of the meeting
 
Introduction of the sprint goals and the whished features
The product owner will present his goals for the sprint. He shows a short summary of all features, he has taken from the backlog for implementation. These features should be shown sorted by priority. Furthermore he may define the time frame, depending if the scrum teams works with fixed or variable time frames for each sprint.

Another possibility, often not mentioned in scrum literature, is to do a feature based sprint with an open time frame. This is useful whenever a specific set of features is needed to release a new version of the software. Of course, to have a sprint with an open end does not fully match with the basic scrum philosophy, but in some situation this procedure may be useful and should be allowed in an agile development process. In this case these must-have-features are needed and therefore it’s not possible to set a time frame and the sprint is done when it’s done. At this point I want to continue with the meeting execution description. But later on, at the end of the article, I want to give you some more insights into the idea of sprints without time frame.

As you can see we may have different possible sprint goals and therefore the product owner must define the goal of the actual sprint, which may be one of the following:

• For this project a fixed time frame for each sprint is given and therefore also this sprint should be done within this time frame.
• There is no fixed time frame defined and so the product owner will set the time frame of this sprint.
• The product owner defines all features which must be implemented and the time frame stays open (it’s done when it’s done).

   
 
Go through the whished features and define the sprint content
The features will now be introduced and discussed in detail. The development team must get a clear understanding of each user story. All open questions will be discussed with the product owner. If there are still open questions which cannot be answered, then these features cannot be implemented within this sprint.

Also statements like the following will not be accepted: “Oh yes, the point is still open. But you can add the feature to the sprint and I clarify the open point tomorrow”. In this case you should not add the feature to the sprint. Everything what’s not defined cannot be implemented. Sprints are short enough so the features with open questions can be moved in the next sprint.

A second prerequisite to add a feature to a sprint is the definition of acceptance criteria. The product owner will define what he wants to see during the sprint review. If it is not possible to define acceptance criteria, maybe because some other parts needed to show the feature are missing at the moment, then the feature cannot be added to the sprint.

After all clarifications have been made, the scrum master asks the development team how many user stories he can add to the upcoming sprint. He begins with the first user story – sorted by priority given by the product owner – then takes the second user story and so on and he will ask the development team whether another feature can be added to the sprint. So one feature after the other will be added until one or more members of the development team have doubts to finish the sprint in the defined time frame. It is very important that the development team will make this decision without external pressure. The development team should give its own commitment for the sprint goal. This is only possible if it can make own decision about the sprint content.

 
Sprints without time frame

Like described above, a sprint can be performed with an open time frame. This is not a normal case and should be done in some special cases only. But then it could be very helpful. I know, to do sprints without given time frame does not fully correspond with the basic scrum philosophy and is more a Kanban-like procedure. But in an agile development environment you should be open for all possibilities to improve your workflows.

Of course, most of the sprints will be done within a given time frame. But there are at least two cases where this fixed time frame can be a big issue for the development. In these cases it is normally not possible for the development team to do a commitment for the sprint goals. But in my projects I have seen teams which will do the commitment nevertheless.

One of these cases is a sprint with a fixed set of features. The product owner has some must-have-features which cannot be done in one sprint. In this case you may do a sprint with open time frame which is finished when all features are implemented. Of course this should only be allowed if the effort to implement these features is not too large. For example if you normally do sprints with a length of two weeks, then you should not start an open sprint and add features with a total effort of six weeks. So the expected total effort of the must-have features should be below two normal sprints.

Another common case is a bug fix sprint. So if you plan a sprint which only or mostly contains bug fixes, then you can also use the nice possibility to do it without a time frame.

Effort estimations for features are never precise. They will always have a variance. But in an experienced team the variance is low and within a sprint the overestimated and underestimated will balance each other. But even for an experienced team it is nearly impossible to the effort estimations for bug fixes. These estimations will always have a high variance and very often these bug fixes are underestimated. So it is nearly impossible for the development team to do a real commitment during the planning meeting 1. Very often the promised goals cannot be reached and the development team will get a lot of pressure during the sprint and will miss the sprint goal which is very frustrating. This can easily prevented by doing a bug-fix sprint with open time frame.

 
Sprint goals according to the economic principle

In a sprint you have two basic goals: finish the sprint within the given time frame and implement the appointed features. But unfortunately these two goals contradict each other. So you only can have one of these goals as your major sprint goal and you may try to reach the other things as best as possible. This procedure corresponds with the economy principle know from business management. This principle has two manifestations which are practicable for your sprints:

Maximum principle

Your goal is to finish the sprint in a given time frame. Within this time you will implement as many features as possible. Therefore, it cannot be a goal to implement all features and normally you will nearly never have a sprint in which all features, selected in planning meeting 1, will be fully implemented. So, it is important to prioritize these features during planning meeting 1, maybe by dividing them into groups (Must / Should / Nice to have). Since the time frame is fixed you will often skip the low-priority features at the end of the sprint.

 
Minimum principle

Your goal is to implement a fixed set of features. To reach this goal you want to spend as minimum time as possible. In this case you will do a sprint with a fixed set of must-have features and an open time frame.

 
Summary

During the planning meeting 1, the project owner and the development team will define the sprint goals. The time frame and features will be fixed and the development team will commit itself to the sprint goals. But keep in mind that the main goals – time frame and features – contradict each other. So you have to define the sprint goals with respect the economic principle.