Original Content

Agile Development: Sprint Planning Meeting

800px-BIS-Sprint-Final-24-06-13-05

In my last post, I talked about the sprint review meeting; this month we look into planning a sprint. As I said last time, this meeting should be separate from the review, both to differentiate the two and to avoid meeting fatigue.

Objective

Sprint planning takes into account the overall project plan and the results of the previous sprint (as presented in the sprint review) and sets out a plan for the next week discrete development time period.

Timing

The timing of the sprint planning meeting is the subject of much discussion, and different teams adopt different conventions based on what they feel is the best fit for their particular process. Personally, I prefer to hold the planning meeting on the same day as the review. While this puts pressure on the Product Owner to quickly adjust planning materials based on the outcome of the review, it has several important advantages:

  • The knowledge acquired during the review meeting is fresh on everyone’s mind. Given that sprints typically end on a Friday, waiting until after the weekend to plan the next iteration can lead to loss of organizational memory.
  • During the time between the review and planning meeting, in theory, no work can be performed (because development priorities have not been set), so minimizing that time is crucial to improved productivity.
  • Given that Agile philosophy aims to decrease overhead, having all the necessary meetings in one day helps to contain that part of the development process and focus the team on actual development work.

My ideal sprint boundary process is as follows: have the sprint review in the morning, then take a break (the sprint retrospective can happen here). After lunch, reconvene and hold the planning meeting.

Participants

The planning meeting should be less open than the review, as it is more concerned with internal team activities rather than disseminating information to as wide an audience as possible. Only team members and the Product Owner should be present, and the Product Owner may be dismissed after requirements have been presented.

Meeting Agenda

Before the meeting begins, the Product Owner should spend some time rearranging the Product Backlog to reflect the current state of the project. This should take into account the results of the review meeting, so if both happen on the same day the PO will need to be quick on her feet (maybe a kind developer can drop by with some takeout for lunch?).

The planning meeting itself can be divided into two major parts. First, the team will move as many user stories from the backlog into the sprint as it thinks it can handle. Initially this will take some guessing in terms of the team’s development velocity, but as sprints come and go the team should acquire a strong sense for how much work it can accomplish in a given time period. Because the PO has updated the backlog priorities, the team should be able to simply take items off the top until capacity is reached. As each item is moved, the team should ask the PO as many questions as necessary to truly understand the scope of the story.

One the sprint bucket is full, the team will move on to the second part of the exercise, which involves taking each item and breaking it down into tasks. The PO should not be needed for this part, as the team should have collected all the information it needs in the first part of the meeting. When an item has been fully dissected and broken down, individual team members should take responsibility for each of the tasks to complete, and dependencies should be identified and documented.

It’s important to remember that sprint planning is not driven by how much work is left in the backlog, but by how much the team can realistically accomplish. If you have 3 sprints left and there are 45 user stories left in the backlog, but the team’s velocity is 10 stories per sprint, you can’t just put 15 stories in the sprint; at that point the team needs to renegotiate scope and priorities, or rethink deadlines. Pushing a team beyond its comfort zone will result in decreased software quality; a better approach is to question scope and differentiate key features from nice-to-haves.

If you want to learn more about sprint planning meetings, you can check out the following resources:

I’ll be back next month to discuss the sprint retrospective.

What are your thoughts on how your organization implements sprint planning? How do you handle the timing of the review/retrospective/planning meeting cycle? What mechanisms do you have in place to handle the tension between what needs to be done and what the team can accomplish?

BIS-Sprint-Final-24-06-13-05” image By Birkenkrahe (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons.