The Agile project management revolution has affected planning more than anything else. Whereas project managers used to create a complex plan of the entire project and then hope to stick with the plan, today project management consists of iterations, or sprints, which adjust themselves to new project realities at each iteration.
But that’s not to say that planning has disappeared. Quite the opposite, in fact. Each sprint gets planned in great detail, and a planning meeting is an integral component of the sprint.
The sprint planning meeting happens on the first day of each sprint. It is attended by the whole scrum team (scrum master, product owner, and development team) and determines which items from the product backlog will be moved to the sprint backlog – that is, performed during the sprint. These items are often further decomposed into tasks.
Sprint planning consists of the following 3 steps:
- Determine the Sprint Goal
- Determine the Sprint Backlog
- Create the task list
Determine the Sprint Goal
The sprint goal communicates to stakeholders what is being accomplished in the current sprint. It provides a general overview of the tasks being completed and what functionality will exist when the sprint has been completed. Stakeholders often want to know what the status of a project is. In agile, there is no rigid project plan (schedule and budget) to reference and compare actual progress to. Hence, each sprint must have an overall description, a one or two line descriptor of what the goal for the sprint is. Here are a few examples:
- SPRINT GOAL: To develop the administration back end of the app, so that administrators will be able to see the trends in money transfers within the application.
Determine the Sprint Backlog
The primary goal of agile sprint planning is to develop the sprint backlog from the product backlog.
The product backlog was developed previously, in the overall product roadmap planning process, which developed a series of “user stories” to describe desired product functionality.
- As <type of user>, I want to <goal>, so that <reason>
For example,
- As a customer, I want to transfer money between my accounts so that I can manage my money.
A typical product backlog might look like this:
| PRODUCT BACKLOG | ||||
|---|---|---|---|---|
| Priority | ID | Item | Status | Estimate |
| 1 | 131 | As an administrator, I want to view a summary of account transfers, so that I can see the trends in money transfers | Not started | 8 |
| 2 | 288 | As a customer, I want to transfer money between my accounts so that I can manage my money accordingly. | Not started | 5 |
| 3 | 63 | As a technical support worker, I want to see what transfers have been completed, so that I can solve customer complaints. | Not started | 13 |
The status (4th column) of the product backlog items should normally be “Not Started” but the odd items may have entered into a sprint and subsequently reverted back to the product backlog due to lack of priority (or some other reason).
As a prerequisite to the sprint planning meeting, the product owner must set the priority level (1st column) for each product backlog item before the meeting starts.
During the sprint planning meeting the development team chooses which items to transfer from the product backlog to the sprint backlog. Hence, an example sprint backlog might look similar to the product backlog:
| PRODUCT BACKLOG | ||||
|---|---|---|---|---|
| Priority | ID | Item | Status | Estimate |
| 1 | 131 | As an administrator, I want to view a summary of account transfers, so that I can see the trends in money transfers | Not started | 8 |
| 2 | 288 | As a customer, I want to transfer money between my accounts so that I can manage my money. | Not started | 5 |
In this example, the development team has decided they can perform the first two, but not the last item, within the upcoming sprint.
The estimates are relative estimates. Many agile teams call them story points, that is, a number of points assigned to a user story to denote its size. Unlike traditional project management, the goal is to accomplish the maximum amount of work, from highest priority to lowest, not to execute a plan to perfection. Of course, a fixed budget might be reached at which point the project must terminate (or obtain additional funds), but the product will have been built at the most efficient pace possible under the fixed budget.
Sprints are intended to be the same length throughout the project, that is, if the project starts with two week sprints it should continue all the way through with two week sprints. The reason for this is that the scrum master can measure sprint velocity. They can determine how many story points were accomplished last sprint, and ensure that the same number of story points are placed within the sprint.
In the above example, the development team has committed to 13 story points. If the previous sprint had 8 story points and didn’t accomplish all of its tasks, it would be ambitious to commit to this level of productivity. That being said, most agile teams increase their velocity over time due to team members learning to work together, and other efficiencies.
Create Task List
The sprint backlog items are often decomposed into a constituent task list, for example:
| 121 | As an administrator, I want to view a summary of account transfers, so that I can see the trends in money transfers | |
|---|---|---|
| Task | Developer Name | Status |
| Set up database | Jon H. | Not started |
| Create admin login page | Bob J. | Not started |
To track the tasks throughout the sprint, the lists and their associated statuses often displayed prominently in the form of a kanban board, with four typical status options:
- Not started
- In progress
- In testing
- Complete
With the kanban board in place, the agile sprint planning process is complete and the project team is ready to spring into action.
Sprint Planning Meeting Length
The length of a sprint planning meeting is about 2 hours for each week of sprint. Since sprints are 1 – 4 weeks in duration, this makes the length of the sprint planning meeting 2 – 8 hours.
This length is timeboxed as the maximum meeting time. Since meetings can get bogged down with discussions and debates, the maximum sprint planning meeting length should be strictly adhered to.
There is no minimum.
Sprint Planning Meeting Agenda
A typical meeting agenda for a sprint planning meeting consists of the following items:
- The big picture
Provide an overview of where the project started, where it is hoping to end up, and how the team has fared so far. This big picture viewpoint is indicative of strong project leadership and gives the team direction and vision. - New information and/or requirements
Stakeholders love to introduce new requirements into projects, thinking that incorporating changes is no big deal. And the whole point of agile is to be able to turn the ship quickly. But these requirements need to be introduced into the product backlog as user stories and estimated by the development team as soon as possible. - Present team velocity
Since the previous sprint velocity is now determined, it can be presented to the scrum team for reference and to assist with populating the sprint backlog. - Team availability
Since sprints are only 1 – 4 weeks long, a team member taking a one week holiday affects the productivity of the sprint. Also, spending time on other projects, taking a course, or other unrelated work will affect the number of story points the team can accomplish. - Create the sprint backlog
The meat and potatoes of the meeting. The development team determines which product backlog items can be accomplished within the sprint, given each item’s story points and the previous sprint velocity. - Divide the sprint backlog into tasks
The development team subdivides each sprint backlog item into its constituent tasks. - Confirm the “definition of done”
The product backlog should already have a “definition of done” assigned to each backlog item. Now that the item has been posted into the sprint for short term development, the definition of done, also known as task acceptance criteria, is confirmed and revised if necessary - Confirm estimates
Often development team members wish to revisit the task estimates when the development is imminent. Although this practice should be kept under control, estimating can be performed again to ensure there are no surprises. - Confirm the plan
All members of the scrum team are asked whether they agree with the sprint plan. If so, the meeting is adjourned.
Sprint Planning Roles
The scrum team consists of three roles, and their contribution to agile sprint planning are:
- The scrum master facilitates the meeting and ensures the logistics are in place (meeting room, teleconferencing, etc.)
- The product owner sets the priority for the backlog items
- The development team decides which product backlog items they can perform during the sprint.
Agile sprint planning is a collaborative process. That is, the development team must decide how much they can accomplish during the sprint. Hence, it is not the scrum master’s job to dictate which backlog items will be a part of the sprint.
Unlike traditional project management, the product backlog items that are chosen to be developed within the sprint are not a concrete plan on which project success is judged. The only thing set in stone is the length of the sprint, and any sprint items not accomplished in this sprint are pushed to the next one (in theory, they revert back to the product backlog and, if its priority remains the same, will be placed into the next sprint).
Sprint planning is the key to great project execution in the new project management paradigm, and we hope this helps you ace the art of the sprint.