Still hearing sprint planning being referred to as a two-part event? Ever been in a sprint planning where developers had to explain their plan of work to the product owner and scrum master?
What you may be dealing with are relics of sprint plannings past. To understand how sprint planning has changed, we’ll take a look at the evolution of the event throughout the years.
The 2009 Scrum Guide described sprint planning as the meeting when the iteration is planned.
The next edition of the Scrum Guide in 2011 changed “iteration” to “sprint,” explicitly calling out that the work to be performed in the sprint is what’s planned at sprint planning, not just the sprint itself.
This language around the purpose of sprint planning remained the same in the 2013, 2016, and 2017 Scrum Guides, finally getting an update in 2020 by indicating that sprint planning initiates the sprint by laying out the work for the sprint.
Notable changes: Overall, the purpose of sprint planning – planning work over a period of time – has remained largely unchanged over the years with just a few minor tweaks to the language used.
In 2009, sprint planning started with two parts: the what and the how. Part 1 kicked off with the product owner presenting the top priority product backlog item and the team deciding on a backlog of work for the next sprint. The “what” part concluded with the team crafting a sprint goal, followed by the “how” portion of designing the work, breaking it into tasks that could be accomplished in a day or less. This list of tasks became the sprint backlog.
The 2011 scrum guide update introduced language around the team “forecasting” their work for the sprint. Instead of a list of tasks, the sprint backlog became the list of selected product backlog items and the team’s plan for implementing them. The Guide added that by the end of sprint planning, the team should be able to explain to the product owner and scrum master how they would work as a self-organizing team to accomplish the sprint goal and create the increment.
The “what” portion of sprint planning was modified in 2013 to have the product owner start by discussing the objective for the sprint and what product backlog items could achieve the goal for the sprint.
The 2020 Scrum Guide update introduced a part three to sprint planning: the “why.” Sprint planning would now begin by crafting a sprint goal as a team, followed by pulling items from the product backlog into a sprint backlog which now also included the sprint goal itself as well as a plan for the work. The update dropped the need for the developers to explain the plan of work to the product owner and scrum master.
Notable changes: The order of operations of the sprint planning agenda moved throughout the years, with creating a sprint goal moving to the start of sprint planning instead of the middle and explicitly serving as the “why” of the sprint. The sprint backlog expanded in scope from a list of tasks to a plan of work with a goal.
The timebox for sprint planning remains unchanged – time-boxed to eight hours for a one month Sprint – though the language on shorter sprints evolved over the years from “for shorter Sprints, allocate approximately 5% of the total Sprint length to this meeting” in 2009 to “For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings,” in 2011 to 2013 and beyond’s, “For shorter Sprints, the event is usually shorter.”
Developers are first mentioned by name in 2011 as the development team who are the sole parties able to assess what they can accomplish in a sprint. Developers remain accountable for planning the work of the sprint by decomposing product backlog items into smaller work items, and from 2011-2020, developers were encouraged to be the ones to invite people outside of the team to attend sprint planning to provide technical or domain advice.
The product owner’s role in sprint planning started in 2009 as presenting the top product backlog priority to the team and being available to clarify product backlog items and make trade-offs. In 2013, the role changed from presenting backlog priorities to presenting the sprint’s objective. In 2020, the product owner’s only mentioned accountability in sprint planning was to how the product could increase its value and utility in the current sprint.
The only mention by name of the scrum master in sprint planning was the 2011-2020 description of developers being able to explain the sprint plan to the scrum master and product owner by the end of sprint planning. Otherwise, it’s assumed that the scrum master would be taking part in all team activities during sprint planning.
In 2009, the sprint goal was created to give the team “wiggle room” regarding functionality. The Guide noted that if work from the sprint goal turned out to be harder than expected, the team could collaborate with the product owner to partially implement the functionality. The sprint goal was a subset of a larger “release goal,” with a separate release planning meeting to turn a vision into a working product.
The 2011 Scrum Guide abandoned both wiggle room in favor of “flexibility” and any mention of partial implementation of functionality, noting that sprint goals could be milestones as part of a larger roadmap.
The sprint goal became an objective for the team in 2013, serving to guide the team on why they were building the increment. The team keeps the goal in mind while working and negotiates the scope of work with the product owner if needed.
The next update to the sprint goal came in 2020 when it became a commitment for the sprint backlog. The Guide noted that the sprint goal is a single objective for the sprint and is a commitment from the developers with flexibility in how they will achieve it.
Notable changes: “Our goal is too hard… let’s only do part of it.” This 2009 sprint goal mentality wouldn’t fly today as the sprint goal has changed focus from achieving functionality to bringing the team together on a single objective.
Want to learn how to improve your sprint goal in under a minute? Check out our video: https://youtu.be/XjRR1YfNX-c
Could your teams be doing more effective sprint planning? Contact Agile Learning Labs to see how we can help!