Scrum is applied by following a set of ceremonies, or meetings. Required Scrum ceremonies include the sprint planning meeting, the daily scrum, the sprint review and the sprint retrospective. Working in time boxes called sprints is also required. Release planning meetings are optional and allow for the planning and forecasting of groups of sprints.
The sprint-planning meeting is held on the first day of every sprint. The ScrumMaster, Product Owner, and Team are all in attendance. The Product Owner presents the set of features he or she would like to see completed in the sprint (the “what”) then the team determines the tasks needed to implement these features (the “how”). Work estimates are reviewed to see if the team has the time to complete all the features requested in the sprint. If so, the team commits to the sprint. If not, the lower priority features go back into the product backlog, until the workload for the sprint is small enough to obtain the team's commitment.
Once the sprint-planning meeting is complete and the team has made a commitment, the team begins to track its progress using highly visible information radiators. These radiators include the burndown chart and the task board.
The task board is used by the team to track the progress of the tasks for each feature. The minimum columns used are To Do, Doing, and Done. Teams will have their daily scrum meeting at the task board, and move items across the board when stating what they did yesterday, what they plan to do today, and what obstacles they are grappling with. See Exhibit 2 for an example task board for a software development project.
Exhibit 2. Scrum Task Board Example
The burndown chart shows the trend line of the amount of work left to do in the sprint. The x-axis is the number of days in the sprint, and the y-axis is the number of hours for all the tasks that were defined in the sprint-planning meeting. Over the days of the sprint, the line indicating the amount of work left to do should trend down to zero by the last day of the sprint. See Exhibit 3 for a sprint burndown chart example.
Exhibit 3. Sprint Burndown Chart Example
Sprint progress is tracked using the burndown chart, the task board, and the daily scrum. In combination, these three things can provide a clear picture of what's being worked on, what's completed, what's still to be done, whether or not it will be completed in time, and what might be preventing the team from meeting its sprint and/or release goal.
At the end of the sprint, the team invites stakeholders to a sprint review meeting where the features that were completed in the sprint are demo'd and feedback is requested. The Product Owner keeps track of the feedback and incorporates it as needed into the product backlog.
Once the review is complete, the team (without the stakeholders) conducts a retrospective to determine what they did well that they wish to continue doing, what they struggled with, and what recommendations they have for change going forward. An action plan is created and these items are implemented over the course of the next sprint, and reviewed for efficacy in the next sprint retrospective.
Release Planning is also part of Scrum, and is a way to do long-term planning for a time box that consists of multiple sprints. This is often done quarterly, and the results of the quarter do not have to be a release to the customer, but may simply be an internal release to confirm system integration and validation. Exhibit 4 shows how release planning fits in with the rest of the Scrum framework.
The entire team attends the release-planning meeting, where the Product Owner presents the features she/he would like to see completed in the quarter. The team does not task out these features however, but instead provides gross level estimates to determine what features can be done in what sprint, and how many of these features can be completed by the end of the quarter. Release planning can be feature-driven (how many sprints will it take to complete this set of features?), time-driven (how many features can we expect to have completed by this deadline?) or cost-driven (given this budget, what does our schedule look like and what features will we have done before we run out of money?).
Exhibit 4. Release Planning in Scrum