Sprint Planning 101: Everything You Need to Know to Plan the Perfect Sprint.

The SeaLights Software Metrics Guide
for Better and Faster CI/CD

What is a sprint planning?

Sprint planning is one of the central ceremonies in the Agile Scrum framework. It is a working session that happens approximately once per week during the sprint, and allows scrum team members to agree on product backlog items that will be completed during the sprint. During sprint planning, teams can also synchronize and agree on the broader context – product roadmap and priorities of the business.

What is a sprint planning meeting?

The sprint planning meeting sets the stage for all the work done during the sprint. It defines two things:

  • The sprint goal – what will be considered success? Does the team need to get a product out the door and deployed to production? Is a certain feature critical to complete? Are we trying to stabilize a release and achieve a certain level of quality? The clearer the sprint goal, the more effective sprint planning will be, and the more effective team members will be in achieving the goal.
  • Sprint backlog commitment – each sprint is a time-scoped unit, in which the team commits to completing certain user stories or development tasks. During the sprint planning meeting, the team agrees which backlog items will be completed during the sprint.

Preparing for a sprint planning session

The following is important to prepare in advance of a sprint planning session:

  • The Scrum team must review backlog items, discuss them in detail, and estimate the work effort required, using hours or story points.
  • The Scrum team and product owner must review the product roadmap – what is the strategic direction of the product and features or capabilities that have been promised to customers, or are demanded by the market?
  • Verify alignment between backlog and roadmap – are the backlog items intended for the coming sprint supportive of the product roadmap? The two will never be completely aligned, and while the organization must allow for some “non-roadmap” work items such as bug fixes or infrastructure work, the team must make sure the product is moving in the direction set by product management.

Sprint planning meeting duration

A good rule of thumb is that a month-long sprint requires four hours of sprint planning; a two week sprint requires two hours. The common best practice is to break sprint planning into hour-long sessions and spread them out across each week of the sprint. This ensures that planning occurs dynamically in parallel to the execution of sprint items, and can take into account lessons learned while the team “hits the ground”.

Who is present in a sprint planning meeting

A basic principle of agile is to bring everyone together. Sprint planning is not done by management and handed down to team members to execute. Rather, planning involves all team members and stakeholders:

  • Scrum team – developers and testers who make up the Scrum team are the most important part of sprint planning, because they came up with the estimates for user stories, and are personally responsible for bringing the stories to completion on time.
  • Scrum master – the scrum master is in the meeting to facilitate and “coach” the team, helping them achieve a balanced sprint plan. A balanced plan takes into account product requirements and priorities, development challenges, team capacity, the velocity demonstrated by the team in recent sprints, and many other factors. It is a list of backlog items that satisfies business needs but is also realistic in terms of the teams’ capabilities and constraints.
  • Product owner – the product owner represents the business and the organization’s customers. What will provide most value to customers? What is the biggest problem that the scrum team can solve? The product owner brings these considerations to the table as a “development wish list”, and starts a negotiation with the Scrum team – what is possible to achieve in the coming sprint.

What’s important in the sprint planning meeting agenda?

  1. Sprint goal and roadmap – the Scrum master launches the meeting by presenting the sprint goal, and putting it in context of the product roadmap. She explains where the team is in the roadmap, what are the next steps and how the sprint goal supports them.
  2. Technical and operational background – all team members exchange information that is essential for the sprint planning discussion, such as which backlog items have recently been completed, significant technical lessons learned from recent work, team capacity and capabilities.
  3. Target velocity – the velocity metric captures the team’s ability to deliver value to customers, in the form of user stories completed and delivered. The Scrum master presents a target velocity for the team in the current sprint (for example, 25 story points), which should be agreed and committed by the team. Target velocity is the basis for sprint planning – the goal of sprint planning is to select the best possible list of user stories to complete in the current sprint, which match the target velocity (e.g. 10 stories with a total estimated workload of 25 story points).
  4. Team capacity – the meeting should establish the capacity of the team in the current sprint, which is calculated as the total number of man hours available for sprint work. This should take into account current team members, vacations, holidays and other factors expected to affect the time available.
  5. Reviewing the Definition of Done (DoD) and acceptance criteria – as part of the general agreement about sprint scope, the Scrum master lists the mandatory and optional items included in the DoD – in other words, what the team needs to do for each user story to be considered “done”. While the DoD typically doesn’t change from sprint to sprint, refreshing it and allowing comments from team members is critical to achieving full commitment to sprint goals. If there are specific acceptance criteria for the current sprint (these may be different in sprints where the product is deployed to production, vs. internally developed product iterations), the Scrum team may negotiate them with the Scrum master.
  6. Deciding on product backlog items to include in the sprint – the central decision of the sprint meeting, what will make the cut and get done during the current sprint. If necessary, backlog items that are too large are converted to epics, split into several stories, and a decision is made which of them can be included in the current sprint.
  7. Deciding on quality and maintenance work to be included in the sprint – this item is often overlooked in sprint planning. The Scrum master must present the current quality of the product, challenges such as production defects and customer complaints, and set clear priorities for maintenance work in the current and following sprints.
  8. Who does what, estimating work owned – based on the backlog items selected, it will become clear how much workload is distributed between specific team members. For example, if sprint work focuses on work in a certain framework, team members who are experts in that framework will be in high demand. If tasks are not evenly distributed given the skills and expertise of the team, the Scrum master can go back and fine tune the list of backlog items for inclusion.
  9. Record assumptions, issues and dependencies – any important external factor that might affect the success of the team must be documented as part of the sprint plan. This might include technology and tools available, previous code available for use, known technical problems in the backlog items, dependencies on other departments, special approvals needed, etc.
  10. Achieving consensus – the Scrum master and product owner must aim for a sprint plan that maximizes agreement between all team members, to achieve the strongest possible commitment to completing the sprint goals. If necessary, the sprint plan can be fine tuned in accordance with objections from the product owner or Scrum team. While consensus is a goal, it is inevitable and normal that some team members will have reservations that cannot be addressed as part of the plan.

Why are quality metrics missing from sprint planning meetings?

Sprint planning meetings are filled with information about user requirements, development constraints, time estimates and product plans. One thing that is usually missing is a clear picture of product quality:

  • Is the product currently satisfying customer requirements from a quality perspective?
  • What are the main challenges on the quality front?
  • Which parts of the product are adequately tested and which are not?
  • At this point in the product life cycle, how much should the team invest in testing and maintenance?
  • What are the top priorities in testing and maintenance for the current sprint?
  • Which areas of the code are of highest priority for testing?
  • Which areas of the code recently changed, and which were not tested in any part of the product’s test suite?

The reason these important considerations are missing from most sprint planning sessions is that development organizations are missing data about product quality. It is not well known how well the product is maintained and what needs to be done to improve software quality.

The test gap analysis report

SeaLights, a Quality Intelligence Platform used by leading software teams, provides a test gap analysis report that can fill in this missing data. It is possibly the best way to plan an effective sprint that can balance between new features and important quality issues.

The test gap analysis report helps teams focus their testing efforts, by highlighting high-risk code areas:

  1. Code that has recently changed
  2. Code that is not tested by any part of the product’s test suite (unit tests, integration tests, UI automation tests, etc)
  3. The most important code areas

By leveraging this report, teams can focus on developing integration tests only in the most important parts of the product, and set a smarter build breaking criteria, significantly boosting sprint productivity.

To learn more, read our white paper about the missing metric for software development teams.