The fourth Agile ceremony I'll discuss and maybe the one I get the most pushback on is the Sprint Planning meeting. When a client new to Agile hears that every two weeks we will conduct a three to four hour meeting to map out the remaining 9.5 days, the initial response is "We can't afford that much non-productive time every 10 days." I am typically able to persuade the client that the half day is necessary for a smooth sprint. If I cannot, it only takes about one sprint of endless questioning and ad hoc meetings to convince the client that the half day is advantageous.

What is the “Sprint” and why plan for it?

Jeff Sutherland and Ken Schwaber, creators of the Scrum development process, Scrum_orgLogo_withoutTag-1.pnghave referred to the Sprint as the "heart of Scrum" in their recent guide on Scrum, released in July 2016. For those new to Agile and Scrum, a “Sprint,” the term used for an iteration in the development process, is a time-box of typically 1-4 weeks with 2 weeks used most frequently. Delivery teams generally perform better when time-box periods are consistent and seldom change. A new sprint starts immediately when the previous sprint ends. During the Sprint a potentially shippable product increment is developed. We say ‘potentially’ because the Product Owner may or may not decide to implement this product increment depending on other release schedules, etc.

The ultimate purpose of the Sprint Planning meeting is to commit to the sprint. To do this there are two deliverables that result from a Sprint Planning meeting; the sprint goal and the sprint backlog.

The Sprint Goal

A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. The team and the product owner write this goal together. The user stories that are pulled into the sprint should further this goal. An example of a sprint goal could be, "Create the user input interface for the scheduling process."

The Sprint Backlog

The sprint backlog consists of those stories that the team has committed to work in the sprint and is a subset of the highest priority items from the Product Backlog. A Sprint Planning meeting is the team’s opportunity to ‘commit’ to the sprint. In other words, when you leave the sprint planning meeting you will have:

  • Established the stories you will be working on in the sprint
  • Discussed all of the salient points of the stories in the sprint backlog
  • Understand the intent of the stories to the best of your ability at this time
  • Asked all the questions you had at the time 

Sprint Planning Meetings are typically 3 to 4 hours long for a two-week sprint and could be longer if the sprints are longer than two weeks. The Produce Owner should attend this call so that all of the team’s questions can be answered. Other stakeholders can attend but it is rare. All stories that are pulled into the sprint backlog should be sized with the tasks broken out based on the team's current knowledge. Tasks may have to be added or removed later. The user stories are sized by points and the tasks are sized in hours. Creating and sizing tasks is a step that is often skipped and it’s too important to ignore. How can you commit to a story when you don’t know its size? Without this understanding you cannot possibly ‘commit’ to the sprint and, of course, the ultimate goal of the Sprint Planning meeting is to commit to the sprint.

Team Capacity

Before you can finalize your sprint backlog you must determine your team's capacity. Typically, a team member is considered to be productive about 6 hours per day. There are meetings, questions about a task, emails to answer, etc. Within a 10 day sprint, one day is used to attend Sprint Planning, Backlog Grooming and Demo meetings. Therefore, within a two-week sprint each team member has 54 hours for full capacity. It is important to take into consideration holidays, vacations or any other event that will impact that time.


Part of the Agile framework includes the guideline that changes are not introduced once a sprint has started. While every attempt is made to comply with that guideline, it is just not always possible. A client may have to change direction to stay competitive. And while you can introduce change, this change is not free. The client has to decide how important this new requirement is and how much cost they are willing to adopt to make this change. Depending on when the change is introduced, it could be very impactful so consider mid-sprint changes carefully. While it does take a good chunk of time, the Sprint Planning meeting might be the most important meeting that the team will conduct.

What are tactics you have used to ensure participation in Sprint Planning? Let us know in the comments section below.