During each two-week sprint, the Scrum process includes these activities so the team has checkpoints to communicate.
Sprint Planning
Attendees: Development team, scrum master, product owner
When: At the beginning of a sprint.
Duration: Usually up to two hours per week of iteration. e.g. a two-week sprint kicks off with a four-hour planning meeting.
Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.
Sprint planning should aim to answer two questions:
- What features can we deliver in this sprint?
- How will we work to achieve these deliverables?
You can plan for the sprint using a Scrum software or the old-fashioned pen-and-paper approach, but you may want your plan to exist as a living document to be updated as needed.
Use the sprint planning meeting to flesh out intimate details of the work that needs to get done. Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint. Foster discussions and gather consensus on the plan of action. Effective planning significantly increases the team’s chances of success meeting the commitments of the sprint.
Daily SCRUM Meeting / Stand-up Meeting
Attendees: Development team, scrum master, product owner
When: Once per day, typically in the morning.
Duration: No more than 15 minutes. Don’t book a conference room and conduct the stand-up sitting down. Standing up helps keep the meeting short!
Purpose: Stand-up is designed to quickly inform everyone of what’s going on across the team. It’s not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answers the following questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
There’s implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the team member who is constantly doing the same thing and not making progress.
Some teams use timers to keep everyone on track. Others toss a ball across the team to make sure everyone’s paying attention. Many distributed teams use videoconferencing or group chat to close the distance gap. Your team is unique. Your stand-up should be, too!
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.
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.
Sprint / Iteration Review
Attendees: Development team, scrum master, product owner & Project stakeholders (optional)
When: At the end of a sprint or milestone.
Duration: Typically 60 minutes per week of iteration-e.g. a two-hour review following a two-week sprint.
Purpose: Iteration review is a time to showcase the work of the team. They can be in a casual format like “demo Fridays”, or in a more formal meeting structure. This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders.
Remember, work should be fully demonstrable and meet the team’s quality bar to be considered complete and ready to showcase in the review.
Sprint Retrospective
Attendees: Development team, scrum master, product owner
When: At the end of an iteration.
Duration: Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint.
Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well–and what didn’t.
Retrospectives aren’t just a time for complaints without action. Use retrospectives to find out what’s working so the team can continue to focus on those areas. Also, find out what’s not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.
Even if things are going well across the team, don’t stop doing retrospectives. Retrospectives provide ongoing guidance for the team to keep things going well.
Scrum teams can use several different formats or activities during this meeting
- Glad, Sad, Mad: Team members pinpoint their feelings to work toward a pleasant experience for every sprint.
- Start, Stop, Continue: Improve the sprint process by asking team members what the team should start doing, stop doing, and continue doing.
- 4 Ls: This method details what each team member liked, learned, lacked, and longed for during the sprint.
Release Planning
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?).
What Happened to the Project Manager?
The project manager often becomes the ScrumMaster. This is not always the case and there are many different transformation permutations. For example, a project manager who has been serving as a domain or subject matter expert might be better positioned as the Product Owner. Or a project manager heading up a team of 50+ people may remain in that role and focus on overall project tasks such as procurement and contract negotiation, while the Scrum teams on the project (remember, a Scrum team is 7 +/- 2 people, so a 50-person project will be made up of 6-10 Scrum teams) each have their own ScrumMaster. In this scenario the project manager assists the ScrumMasters in coordinating, strategizing, and removing roadblocks.
What Happened to Using Detailed Tasks and Task Estimates to Generate Projections?
Traditional estimating and planning uses a bottom-up method, where all requirements must be fully defined, with tasks then created and estimated based on this fixed scope. Agile estimating and planning instead uses a top-down method to forecast. Gross level estimating at the feature level is often done using a technique called planning poker, with estimates given in points using the Fibonacci sequence. Teams determine their velocity in points, i.e. how many points on average can the team complete in a sprint. Cost per point is determined by calculating the loaded salaries of the team for period x, then dividing that by the number of points completed in period x. Once you have your team’s average velocity and a gross-estimated product backlog, you can forecast project milestones and completion dates, as well as the cost per point and thus forecast project cost.
What Happened to Gantt Charts and Other Documentation?
Gantt charts are not typically used on Scrum projects. Burndown charts (both sprint burndowns and release burndowns), task boards, backlogs, sprint plans, release plans, and other metrics charts are used instead to communicate progress, status, and forecasts. A variety of agile project management tools exist to provide this type of dashboard reporting, including plug-ins for Microsoft Project.
The only artifacts Scrum requires are the product backlog, sprint backlog, release burndown, and sprint burndown. All other forms of documentation are left up to the team to decide. The agile rule of thumb is that if the artifact adds value and the customer is willing to pay for it, then the artifact should be created. Artifacts created because “it’s on the checklist” or “we’ve always done this” are items that should be considered for elimination. Documents required for governance issues (audits, accounting, etc.) must still be created, but often can be streamlined.