A Sprint Retrospective Meeting can be one of the most effective activities you can use in an Agile Project. The Concept of Retrospectives is not new to Agile Project Management,. “Lessons Learnt” and “Post-Mortems” are Retrospectives and are typically held at the end of a Project.

Kinds of Sprint Retrospective

Generally, in Agile Environments a Sprint Retrospective is held at the end of every Sprint. Additionally a Release Retrospective is held at the end of a Release. A Sprint Retrospective will consist of the Development Team. The Product Owner should also be welcomed. A Release Retrospective must include everybody who played a part in the Release. A Retrospective Meeting needs to review all the Events in a Sprint or Release, so do not skimp the time required. Set aside an hour for a Meeting to discuss a Sprint, while a Release Meeting need to be double that. Up to half a day may be required depending on the scale of the Project.

You are looking to build new efficiencies for your next Sprint or Release. The Retrospective is the best way to identify and implement these improvements. As everybody becomes more familiar and comfortable with the Meeting, the time taken should also reduce. The meeting outputs should also improve. To take full advantage of the effectiveness of the Meeting, circulate an agenda. Include any extra information that needs to be considered before the Meeting. This information should be sent out 3 to 5 days ahead of time. This encourages the Team to apply their minds in advance to any notable wins and obstacles experienced.

Sprint Retrospective Fundamentals: the Four Questions

The master of Project Retrospectives, Norm Kerth, framed 4 Questions that can be explored in any Retrospective:-.

• What Did We Do Well?
• What Should We Do Differently Next Time?
• What Did We Learn?
• What Still Puzzles Us?

You will notice that first off, these are quite thorough Questions for evaluating the Work under Discussion. Secondly, the questions are all framed favourably. There is much Opportunity for playing the “Blame Game” in Retrospectives. One of the best ways to prevent the blame game is by using positive language in discussing what took place. There will always be errors and scenarios that were not handled optimally; the point of the Meeting is to understand why they took place and how to prevent them moving forward.

While these questions in themselves are easy, getting the desired answers is a lot more complicated. If you are Facilitating the Meeting, you must ensure that everybody has an Opportunity to contribute. Everyone must have the opportunity to offer an opinion. You can collect the feedback either via Recording discussions for later transcription or by means of sticky notes on the walls or whatever the standard is for your Organisation.

Sprint Retrospective – What Did We Do Well?

It is also essential to start with successes. Record these successes, so that the success and the way it was obtained is not forgotten. If the success was due to a fortunate break, or due to the fact that it was executed extremely well, this should be recorded. Undoubtedly if luck was involved, this is not likely to happen again. It would therefore not be an improvement to take forward into the next Sprint.

An example of an improvement to be repeated could be:-

“We invited the Product Owner to the Stand-Up Meeting as an observer, which helped him to re-prioritise the Product Backlog when he understood our challenges”.

Sprint Retrospective – What Should We Do Differently Next Time?

This is a more tactful way of stating “What Went Wrong?”. It is tailored towards getting frank conversation and feedback on issues that occurred. The phrasing likewise recommends that we need a service or mitigation to apply if the scenario occurs again. Answers to this question must be neutral. For example:

“We wrote two sets of very similar Code for Stories A and C”, instead of “We should have reused the Code from Story A for Story C”.

You are not Working on solutions at this stage.

Sprint Retrospective – What Did We Learn?

This is where each Team member uses some introspection to how they Work. Maybe one of the Development Team hurries into coding too soon. This may mean they don’t analyse or understand the user story. It may be found that this results in more Rework or a longer testing cycle. This is likewise an Opportunity for Team members to share experiences.

We found these books great for finding out more information on Agile Scrum:

Sprint Retrospective – What Still Puzzles Us?

This question unearths prospective Risks and knowledge gaps in an un-threatening method. Framing the problem as a concern welcomes the rest of the Scrum Team (Scrum Master, Product Owner and Development Team) to respond. They may concur and they may have had a similar challenge. The problem might be a gap in Product knowledge. It may be a misunderstanding of what Benefits the Project as a whole will give the Company.

Retrospective Fundamentals: Deciding on Changes.

Until the Four Questions have been dealt with, there ought to be no attempt to come up with solutions and Changes:-.

• It will not be possible to use every Change raised in the next Sprint or Release. Similarly to the Product Backlog, the points raised must be prioritized. The Team must agree with the changes. The Changes can then be applied for the top 5 or 10 cases. These takeaways will be used in the next Sprint or Release.
• This is an Opportunity to share your outcomes with the rest of the Company. Knowledge can be shared between the other Scrum Teams on the Project (if it is a big Project). The knowledge can also be shared with the Stakeholders. The other Teams may be experiencing comparable problems and can embrace your Changes instantly. The Stakeholders would have been aware that things did not go so well. Their confidence levels in the Project will improve when they see feedback on how these issues will not reoccur in the future.

Making the Retrospective a Happy Place.

To keep this article brief we have not looked into the numerous tools and methods that you can apply to engage the Scrum Team members and make them keen to take part. What is explained is the Framework, which may appear rather dry and dreary. You can gamify your Retrospectives; they are long Meetings and you want to create some fun. Most of these techniques are designed to improve the feedback you get from the Meetings. What is essential is that everybody in the Meeting feels valued and are not threatened. Norm Kern developed the “Prime Directive” which specifies:-.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

At the end of a Project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.

 from Project Retrospectives: A Handbook for Team Review

Use this as your yardstick for a successful Retrospective.