Context: Agile Product Development.
Agile (and scrum) is all about adaptation, quick improvements. I have written a a bit on making 2 week sprints effective & conducting sprint demos. But Sprint Retros are at the heart of agile are an equally critical part of the scrum / agile process.
At times,the retrospective meeting can be very time consuming, sometimes goes on for more than an hour. Here is the one change that could make it highly efficient :
- Have a standard list of fine grained questions about the sprint for everyone one to answer. And they can only choose to answer between – agree / neutral / disagree. Later provide details about their opinion.
- Put this list on a shared space ( either a google spreadsheet or the wall where people can vote using markers/ stickies or any other tool) and request all the team members to fill it up in the first 5 minutes of the retro meeting.
- Start with questions for which everyone has voted – ‘agree’. You can ask the participants to provide some quick explanation on what makes them agree and what is it that the team should continue to do. This should be about 5 minutes.
- Next go to those questions which have ‘neutral’ or ‘disagree’ votes and then do the same thing – ask participants to provide details on why they disagree. This is the main thing. Create action items out of this discussion and assign owners. Spend the bulk of your time here.
Having that standard list to begin with will save you a ton of time. It had started saving around 40-50% time for my retrospect meetings.
In-case its helpful, here is the list of questions I had used for my meetings, you can make your own
- Did we meet our sprint goals ?
- Did we do well w.r.t work allocation ? Our goal is to ensure that the allocation is not too heavy for one individual or a few individuals but is mostly evenly spread.
- Did we execute well ?
- Did we avoid fire fighting /working late in the last 2 days of the sprint ? ( We want to make sure that we do not have too much to do on the last 2 days)
- Did we do well on estimation ?
- Were the stories clear ? Was there no confusion w.r.t what was expected or acceptance criteria ?
- Did we do well on collaboration w.r.t UX, Product and Engg ?
- Did we do well on quality ? Our goal is to ensure that we dont leave major bugs as spill overs
- Did we do well on automation/ code coverage ?
- Do we feel equiped to deliver with speed ? Do we feel we have all we need for being productive ?
And if you are looking for material on how to conduct retros – here is detailed article by Microsoft.
Do give this change a try & share your thoughts on the above.