Continuous Automation: DevOps • Agile • Leadership • Business Innovation: What the hell happened?
Continuous Automation: DevOps • Agile • Leadership • Business Recovering from Failure
Continuous Automation: DevOps • Agile • Leadership • Business You’re living in a buzzword world

Agile 101: Effective Sprint planning meetings

Introducing the Sprint Planning Meeting

In Agile development organizations most often apply a minimum of three core meeting ceremonies (The Sprint Planning Meeting, Daily Stand-ups, and Retrospectives). These ceremonies respectively identify the beginning, middle, and end of a given iteration. In this article we’ll explore the sprint planning meeting, it’s purpose and some ways for an Agile practitioner to conduct a successful sprint planning meeting.

In the wonderful world of Agile, the Sprint Planning meeting  signifies the initialization of a new sprint and the development of mutually agreed upon features or bug-fixes. For those unfamiliar with the concept of a sprint (also known as a time-box); it’s simply represents a previously agreed upon and reoccurring iteration time period (Typically 1-2 weeks). During a ‘sprint’ developers, QA folks, and related staff work hard to implement and complete the development of a portion of a software system. By the end of the sprint (usually 2 weeks) the team will have (hopefully) completed the mutually agreed upon work, and delivered it to a customer.

Sprint planning meetings are arguably one of the most critical ceremonies in Agile. The meeting itself provides a forum for developers, product owners, quality assurance personnel, management, and related staff to gather together and mutually agree upon the work items that will go into the upcoming sprint. The input of this meeting in most traditional shops is the product Backlog. That is to say a compiled list of business wants, needs etc. The general idea of the sprint planning meeting is described in the illustration below.

Sprint Planning

Who Should Attend?

Generally sprint planning meetings can be an open invite for the business (anyone interested can attend). The individuals required to attend the sprint planning session should be the following:

ScrumMaster/Agile Coach – facilitates the meeting
Product Owner – The person/people who represent the customer for the output of the sprint.
Delivery Team/Agile Development Team – Individual contributors working on the sprint tasks

The people listed above are mandatory for the sprint.  As mentioned before the sprint planning meeting should not be a closed door session however keeping it within scope and focused is an important goal. To this end ancillary staff not participating in the sprint (listed above) should remain quiet.

Effective Sprint Planning Meeting Tips:

Now that we have a general idea of the concepts behind the sprint planning meeting, let’s take a look at some ways to get the most out of the sprint planning meeting and make it an effective conduit for Agile oriented teams.


TIP# 1: Allow individual contributors the opportunity to weigh in on effort and scope (make it collaborative)

One of the core philosophies surrounding Agile [via the Agile Manifesto] is self organized teams. A self organized team is a group of motivated individuals who collaborate to deliver something awesome. They are not motivated by management telling them to march but instead are motivated internally. It is important to ensure that while prioritizing the backlog into actionable tasks is important, it’s equally important to ensure the planing session does not come across as a top-heavy dictator based prioritization ceremony. This can be a challenging concept to grasp but it IS possible to set priorities without becoming a dictator. It simply means instead of a manager saying “We need X, Y and Z completed this sprint” instead they might say “Let’s all rally around a huge win!” or “Customer X would LOVE us if we got this functionality implemented”. Phrasing in this scenario is key and it’s important to allow the individual contributors an opportunity to voice any concerns, outline any timeline dependencies or raise any foreseen red flags.


TIP #2: It’s a sprint not a marathon

Agile ‘sprint’s’ work best when shorter time scales are applied. As such it’s important to keep the planned work within reasonably obtainable scope. To help ensure your sprint doesn’t become a marathon consid
er the following.

  • If you cram too much into the sprint, you wont get much out of it
  • If you make the sprint last 6 months you are doing Waterfall
  • If you push your team too hard to accomplish too much in a short time period you will burn your team out

The take away from these bullet points is to simply to be reasonable and aware. Reasonable about expectations and aware  of scope creep or excess workload.


TIP #3: Create proper stories with actionable and achievable content

Ambiguity in requirements leads to ambiguity in development and sloppy deliverables. To help avoid creating sloppy implementations story writing is important. When writing out stories it’s absolutely critical to provide at a minimum the following:

  • Detailed implementation actions
  • Detailed acceptance criteria
  • As much information on the design as possible

An overly explicit story will better prepare the team to succeed in the execution of the sprint.


 TIP #4: Create and follow a Sprint Planning Meeting Agenda

Meetings are pointless if there is no specific output or actionable task(s) agreed upon by the end of the meeting. Outlining and following a sprint planning meeting agenda will help keep everyone focused on the content of the meeting and walk out with actionable stories for the sprint. As your Agility improves so will (hopefully) the efficiency of the meetings conducted. To help an Agile practitioner conduct an effective sprint planning meeting proper preparation is required. Let’s look at an example of an actual sprint planning meeting agenda.


  1. Opening & Introductions – Everyone to sits down, the scrum master reviews the agenda and the team gets focused
  2. Vision – The product owner speaks to the team and provides a high level overview of what the team is working towards
  3. Sprint Theme / Name – Management and the team weigh in and decide an overall theme/name for the sprint
  4. Team Capacity Planning – The team identifies any potential personnel outages or vacations
  5. Backlog Review – The team reviews the current backlog and selects items that will be delivered this sprint
  6. Story Writing – The team creates specific stores & tasks for any ambiguous or vague backlog items identified during the backlog review
  7. Sprint Backlog Created – The team finalizes the stories, epics, or tasks that will be done by the end of the sprint
  8. Sprint Commit Review – The team looks over the sprint backlog and verifies ALL items can be completed during the sprint
  9. Parking Lot – The team interacts and engages in any pre-sprint execution engineering related conversations


TIP #5: Estimations are exactly that

No one is perfect about estimating the amount of work involved in developing out a story. Sometimes even well intentioned people miss their estimates. One way to help avoid a failed sprint is to reduce the capacity of the team just a bit. By reducing capacity your team will have enough padding around their estimations to account for underestimated story sizes. In addition, padding your stories, and under budgeting will help ensure the team is be better geared to succeed in the sprint goals and not likely to burn out.


Hopefully this article will help Agile practitioners out there conduct more targeted and focused sprint planning meetings.  If I missed anything or you would like to see something added, drop me  a line in the comments below.



[Total: 0    Average: 0/5]

Category: AgileEngineering

Share this Article

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Article by: jmcallister