Making Sprint Retrospectives Really Effective (Part 4 of 4)
Once a Scrum team has discussed and developed a SMART action plan in a Sprint Retrospective session (as described in Part 3 of this blog series), I recommend capturing all the results from the Retrospective session and SMART actions into the agile tool being used, such as VersionOne. This would allow easy planning, tracking and closure of all those actions in subsequent sprints. Each action coming from the SMART action plan needs to be converted into either an item of a concrete checklist, or some sort of reminder to reinforce the team’s behavior change / or specific stories in the agile tool. The following table illustrates stories and epics added to an agile tool resulting from a SMART action plan. It may not be possible for the Scrum team to break down a new action story into its tasks and assign tasks to team members in a Sprint Retrospective session itself; in that case, this effort needs to be completed in the planning workshop or session for the upcoming next sprint. Ideally, a Scrum team should make its best effort to implement a complete action story in the very next sprint in order to improve its agile process. For example, procuring a projector for the team’s use can be done in a single sprint, as most likely, it usually does not involve complex and time/consuming purchasing and approval cycle. Most projectors are inexpensive nowadays and are non/capital items. If an action story requires substantial effort that cannot be fully completed in a single sprint, the story should be modeled as an “epic” and then implemented over multiple sprints. For example, investing in a Continuous Integration infrastructure would be a good candidate for an epic, which is investigated, implemented, tested and fully deployed over multiple sprints. With the above approach, the agile tool will have a list of stories and epics coming out of Sprint Retrospective sessions. A subset of them should be taken for completion in the next sprint. Note that in a given sprint, the team should be working on some stories that came out of the Sprint Retrospective from the very last sprint, while some stories may be coming from even earlier Sprint Retrospectives as those stories may either belong to epics or were not completed (for some reason) in the last sprint. In any given sprint, the Scrum team needs to set aside 5% to 10% of its capacity to improve its agile process based on the SMART action plans developed in the past. Otherwise, the team is simply not serious about executing its own SMART action plan; i.e., the SMART plan would remain “paper smart” only, and fail to produce intended results and benefits. The ScrumMaster should keep and maintain the following information in the agile tool capturing the results and actions from the Scrum Retrospective sessions.
- Sprint_Retrospective file for each Retrospective for a product over all releases
- Key statistics files, usually generated as reports (PDF files) using the agile tool, for each Retrospective for a product over all releases
- Sprint_Retrospective_Log file that keeps a running log of results and actions from each Retrospective
- Top 3 factors that worked well (based on the team consensus)
- Top 3 most problematic factors (based on the team consensus)
- Key Statistics: actual reports (as PDF files) are captured in the agile tool as stated above
- Top 3 impediments or impediment patterns
- SMART action plan
- Actions in the SMART action plan are mapped on to stories and epics (and their stories). A subset of these stories and epics (captured in all Sprint Retrospectives) is taken up to work on in the next sprint for improving the agile process. These stories (and their tasks) are planned, estimated, tracked and closed similar to any other stories in a sprint. They are also reported on in the Daily Scrum meetings. This allows all work for agile process improvement to be treated as a first/class citizen, and managed with vigorous discipline. Otherwise, I have seen many agile teams making a great SMART action plan during each Sprint Retrospective, but failing to act on those plans in a disciplined way.
The Sprint_Retrospective_Log allows a Scrum team to:
- Clearly see linkages among different Sprint Retrospectives of a product over multiple release cycles
- Clearly see recurring issues and various trends
- Get critical information to be used during Release Retrospectives, an important topic which I will cover in a future blog
- Provide valuable information to organizational management, such as Director and VP of Engineering, Project Management Office (PMO), etc.
- Get a broader perspective on its own agile process improvement journey undertaken sprint by sprint.
If you would like to receive a single file version (as a PDF document) of this 4/part blog series, please send me an email at Satish.Thatte@VersionOne.com requesting the document. I hope you will be able to apply the information in this blog series to your own Sprint Retrospective sessions and improve your agile process sprint by sprint. Got any tips of your own to share? What has worked for you? What has not? Part 1 Part 2 Part 3