Daily Scrum

Once the Sprint has started, the Team engages in another of the key Scrum practices: The  Daily Scrum. This is a short (15 minutes or less) stand-up meeting that happens every workday at an appointed time, and everyone on the Scrum Team attends; in order to keep it brief, everyone stands (hence “stand-up meeting”). It’s the team’s opportunity to report to itself on progress and obstacles. One by one, each member of the team reports three (and only three) things to the other members of the team: What they were able to get done since the last meeting; what they’re hoping to get done by the next meeting; and any blocks or impediments that are in their way. The ScrumMaster makes note of the blocks, and then helps team members to resolve them after the meeting. There’s no discussion during the Daily Scrum, just the reporting of the three key pieces of information; if discussion is required, it takes place right after the meeting. The Product Owner, Managers, and other stakeholders can attend the meeting, but they should refrain from asking questions or opening discussion until after the meeting concludes – everyone should be clear that the team is reporting to each other, not to the Product Owner, Managers or ScrumMaster. Some teams find it useful to have the Product  Owners join and give a brief daily report of their own activities to the team, though this is at the team’s discretion.
After the meeting, the team members update the amount of time remaining to complete each of the tasks that they’ve signed up for on the Sprint Backlog .Following this update, the ScrumMaster adds up the hours remaining for the team as a whole, and plots it on the
Sprint Burndown Chart. This graph shows, each day, how much work (measured in hours or days) remains until the team’s commitment is completed. Ideally, this should be a downward sloping graph that is on a trajectory to hit zero on the last day of the Sprint. And while sometimes it looks like that, often it doesn’t. The important thing is that it show the team their actual progress towards their goal – and not in terms of how much time has been spent so far (an irrelevant fact, as far as Scrum is concerned), but in terms of how much work remains – what separates the team from their goal. If the curve is not tracking towards completion at the end of the Sprint, then the team needs to either pick up the pace, or simplify and pare down what it’s doing. While this chart this can be maintained electronically using Excel, many teams find it’s much more effective to do it on paper taped to a wall in their workspace, with updates in pen; this low-tech solution is fast, simple, and often more visible than an electronic one.

Sprint Retrospective

Following the Sprint Review, the team gets together for the Sprint Retrospective. This is a practice that some teams skip, and that’s unfortunate, because it’s the main mechanism for taking the visibility that Scrum provides into areas of potential improvement, and turning it into results. It’s an opportunity for the team to discuss what’s working and what’s not working, and agree on changes to try. The Scrum Team, the Product Owner, and the ScrumMaster will all attend, and a neutral outsider will facilitate the meeting; a good approach is for
ScrumMasters to facilitate each others’ retrospectives, which enables cross-pollination among teams.
A simple way to structure the Sprint Retrospective is to draw two columns on a whiteboard, labeled “What’s Working Well” and “What Could Work Better” – and then go around the room, with each person adding one or more items to either list. As items are repeated, checkmarks are added next to them, so the common items become clear. Then the team looks for underlying causes, and agrees on a small number of changes to try in the upcoming Sprint, along with a commitment to review the results at the next Sprint Retrospective.
A very useful practice at the end of the Retrospective is for the team to label each of the items in each column with either a “C” if it is caused by Scrum (in other words, without Scrum it would not be happening), or an “E” if it is exposed by Scrum (in other words, it would be happening with or without Scrum, but Scrum makes it known to the team), or a “U” if it’s unrelated to Scrum (like the weather). The team may find a lot of C’s on the “What’s Working” side of the board, and a lot of E’s on the “What’s Not Working”; this is good news, even if the
“What’s Not Working” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.