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.