How to run a sprint retrospective?

Sprint retrospective is performed at the end of the sprint to decide and act on the practices and protocol followed by the Product team. Sprint retrospectives are performed in accordance with SPACE protocol.

Purpose of the retrospective: to evaluate and decide whether a product is being delivered right. This evaluation comes from assessing practices and protocol value and usefulness:

• practices and protocol focus on the needs / backlog items that were included with the sprint
• practices and protocol stimulate achieving sprint goals on time
• practices and protocol are convenient and efficient to follow

Expected results of the retrospective:

• collective wisdom is updated and enhanced — practices and protocol are updated, black book is rehearsed, framework principles and values are acknowledged
• decision to adjust practices and protocol is made — product team confirms altering the way it is managed and operates in its entirety or partially
• possible adjustments to practices and protocol are identified and formulated — feedback items are grouped, structured, and analyzed as practice and protocol modifications
• team feedback is collected — opinions of the team members on the practices and protocol are gathered
• full sprint recap is performed — recap assumes presenting all sprint outcomes, performance metrics, successes, issues, failures, and disasters, no exclusions or omissions are made

Areas to be covered by the retrospective: to perform a thorough research and reflection on team performance and to provide a focused improvement following areas would be covered:

• key outtakes — Did we reach sprint goals? What did we learn? What key conclusions did we make? How do we evaluate our interaction with clients and partners?
• sprint results — Were the sprint tasks achieved? What was achieved at the task level? What metrics demonstrate task achievement? How do we evaluate results over task — success, issue, failure, or disaster?
• black book — What were our biggest misses? What were the reasons and what we didn’t expect or account for? How can we prevent another occurrence of the same or a similar issue? What could become a disaster in the coming sprints? What should be considered in the plans, protocol, approaches in dealing with clients and partners?
• specific results — What has been done good or perfect? What hasn’t been done and why? What were the reasons and what we didn’t expect or account for? What was being done above the sprint scope? What tasks were cancelled or dropped during the sprint and why? What should be done in future to adjust for that?
• protocol — What worked in the proposed approach — and has to be kept and strengthened? What didn’t work in the proposed approach — and has to be improved, adjusted, or dropped?

What needs to be done:

• recap planning — gather data on sprint outcomes, performance metrics, consider if sprint goal was achieved, identify successes, issues, failures, and disasters, make the discussion script, understand team members’ availability, book the place, resolve technical issues, prepare FAQs not covered in the scenario / script, decide on the way to address question during the recap, identify areas and questions for team members’ feedback
• recap running — perform recap
• collecting feedback — gather team members’ feedback on the matters relevant and identified by the product team
• identifying and formulating adjustments to practices and protocol — transform feedback to potentially actionable items of practices and protocol
• documenting decisions — capture what needs to be done: decisions regarding adjustments to practices and protocol
• moving on — let go!

Tools to be used:

• closing memo
• black book