How to include frequently neglected topics in your Retros

When it comes to facilitating retrospectives, there’s no shortage of activities to choose from to encourage reflection on the Sprint. Multiple activities can be combined to set the stage, generate insights, decide what to do and wrap up the event. It can be challenging to keep such a packed event within its timebox and teams often run the risk of neglecting important topics. 

“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.” The Scrum Guide 2020

While the Scrum guide seems to be quite specific about inspecting how the last Sprint went, assessing it in isolation could limit the value generated by the event. By focusing solely on events from the last Sprint, teams could miss an opportunity to reflect on progress made over a longer period of time, to check whether they are upholding agreements made in previous Sprints, and to give ample consideration to the future. 

There are also subjects which may generate less enthusiasm but nonetheless fall under one of the categories the team should inspect (individuals, interactions, processes, tools, and their Definition of Done). Some targeted facilitation may be needed to encourage the inspection of the topics such as those mentioned below, that team members may be less likely to raise.

Definition of Done 

The Definition of Done doesn’t always get the attention it deserves, with some teams even neglecting to create one. It is vital to ensure transparency over the state of the product increment so that the Scrum team and their stakeholders share the same understanding of what “Done” actually means, and what level of completeness and quality to expect from the product increment. 

While most teams are good at creating a Definition of Done and sticking to it, it may be less common for them to update it during the retrospective. Actions might be agreed during the event that warrant being formalised within the Definition of Done to ensure they don’t fall by the wayside. 

The Definition of Done should evolve and become more comprehensive as the team learns more about the product and discover more effective ways of working. Scrum Masters can help to facilitate this process during the retrospective.

A good Scrum Master helps the team to meet the Definition of ‘Done’ at the end of the Sprint. A Great Scrum Master helps the team to extend their Definition of ‘Done’. –Geoff Watts, Scrum Mastery.

A good retrospective activity to try with a team that hasn’t reviewed their Definition of Done for a while, is to ask members to list the criteria it includes (without looking at it beforehand, of course) to see whether they leave any out or come up with additional ones. It could prompt some valuable discussions around the points missed and whether they are still valid, and whether the additional ones should be included. Some healthy competition could be introduced by splitting the team into sub-teams to see who can get the full set. 

Actions from the previous retrospective

An energiser is the obvious first activity to kick off the meeting and can lead nicely into another equally energising activity to generate feedback on the Sprint. Before you know it, the timebox has expired and no one remembered to mention the actions agreed upon in the previous retrospective. Checking up on previous actions can play a vital part in preventing the recurrence of an issue or in mitigating a risk. It’s better to be reminded of the preventative action required than to wait for a major issue to serve as a much harsher reminder. 

So what’s the best way to make sure previous actions get discussed without breaking the flow? Actions could easily be worked into whichever activity is selected to generate feedback on the Sprint. Someone (either the individual action owners or facilitator) just needs to bring them to the retrospective. They can easily be added to post-its for the team to place in the relevant category (depending on progress made) along with feedback on the Sprint. GoRetro has a special drawer to store all the action items from previous Sprints, making them prominent and accessible so that they are easy to keep in mind. 

Estimate accuracy

Estimates aren’t everyone's favourite topic. Some team members might not deem something prone to inaccuracy to be discussion worthy, especially if the imprecision of the estimate didn’t derail the Sprint Goal. However, if estimating is part of the team’s process then it warrants inspection and optimisation to ensure the benefits are maximised. Of course, if the team fails to see any benefit, they should discuss whether it’s worth the effort.

I’m not suggesting that you spend every retrospective picking over each backlog item, but significant variances could drive insightful discussions. Teams who accept variances without question can miss the opportunity to share knowledge and improve the accuracy of future estimates to improve planning and forecasting. 

The team might want to retrospectively assign actual efforts to the Sprint backlog items, using planning poker or their preferred method of estimation, or they could simply scan the Sprint backlog to see whether any items stand out as significantly under or over estimated. 

Recognising progress over time 

If teams restrict their reflection to the last Sprint, progress they’ve made over a longer period of time might go unrecognised. It can give everyone a boost to realise how much they’ve improved as a team over time. On the flip side, they may not have made as much progress as expected and reflecting on the past could remind them of goals and agreements yet to be achieved. This reminder could encourage an increased focus on improvement.

To compare progress over time, teams will probably need some help remembering their previous Sprints. Scrum Masters can help jog memories by bringing notes and actions from previous retrospectives for them to reflect on. The team can then discuss whether negative aspects have got better or worse and whether positives have continued on an upwards trajectory or seen a decline.

Regular team health checks can also be useful for measuring progress. The Spotify Model (and similar alternatives) can help teams to measure their satisfaction with various internal and external factors. They vote with simple traffic light symbols, green being positive, red negative and amber in-between, and the results can be displayed in a chart with upward and downward trends over time represented by arrows. 

Team charter 

Most teams include a charter or team agreement in their early activities as they form. Unfortunately such artefacts can often receive less attention as time goes on. They may get buried somewhere in a wiki or fade into obscurity on a board in the office, covered up with the more recent scribblings. It’s worth resurrecting the charter for inspection in a retrospective. Have team members continued to behave as they intended? Do they abide by the rules they set themselves? If not, try to find out what led to the deviation.

A team charter isn’t set in stone; it’s a living document which should be inspected and adapted as the team learns what does and doesn’t work well. It can be valuable for the teams to assess themselves against and revisit as new members are introduced. 

The future 

“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” The Scrum Guide 2020

Retrospective by definition means looking back, but the purpose of the event is to improve in future. It’s common for teams to focus largely on the near future, discussing what to improve in the next Sprint. Some teams might get stuck in a rut of using a similar cycle of activities which don’t encourage them to consider future opportunities and risks.

It’s worth thinking beyond the next Sprint and airing hopes and concerns for the less immediate future. Activities such as the sailboat retrospective (or those using alternative vehicles to stimulate similar conversations) encourage teams to consider the rocks (risks) they could be heading towards or the sunny skies on the horizon (opportunities). 

Conclusion 

There are a number of ways to ensure retrospectives cover as many bases as possible:

• Try not to cram in too many activities as you’re more likely to run out of time to discuss important topics.

• Vary the activities to include those which encourage futurespection as well as retrospection. 

• Have previous retro actions ready on post-it’s to include in any feedback generating activity. 

• Consider whether any agreed-upon actions require a revision of the Definition of Done or Team Charter

• Schedule regular reviews of the Team Charter and Definition of Done 

• If estimation is part of the team’s process, inspect it. See what can be learnt from any significant variances between estimated and actual efforts.

• Scrum Masters can facilitate discussions around subjects which aren’t put up for discussion by developers. The lack of attention could suggest there is little scope for improvement or it might indicate acceptance of the status quo. 

• Choose one focus area for the retrospective to allow for deeper discussions which might not usually happen (the focus could be one of the often missed topics above that the team hasn’t paid enough attention to). Throwing a focused retrospective into the mix occasionally should prevent the event from getting repetitive.