What is an Agile Sprint Retrospective?

In my last post, I explained that in agile software development methodology, work is completed in sprints. Although having sprint meetings every week is helpful, it is important that the team members have a meeting to clearly review other key information, such as: factors that have contributed to the successful completion of tasks and deterrents to successful program completion. This is exactly what agile sprint retrospectives are for! In this blog post, we are going to examine what agile sprint retrospective are and why they are important.

Sprint retrospective meetings help agile teams to stay on track in the project development process. It is held between the end of the current sprint and the start of the following sprint. Retrospectives are attended by the team members, the project manager, a note taker and a facilitator. The facilitator acts like a neutral person to facilitate and lead the meeting, so that the team is able to make important decisions by the end of the meeting. (Derby & Larsen, 2006) According to Mahnic and Zabkar (2008), during a retrospective, the main topics of discussion are: the size of code of each product backlog item, the total number of product backlog items that have been completed and the total number of product backlog items that are pending. Unlike Scrum meetings that are fifteen minutes long, Sutherland and Schwaber claim that retrospectives can be up to four hours long (Hossain, Babar & Paik, 2009). Due to the length of the meeting and the participation of multiple onshore and offshore members, it is often difficult to find reliable forms of communication. Hence, these meetings are sometimes held in a synchronous format (such as video call) and other times held in an asynchronous format (such as posting the results on Wikis). (Hossain, Babar, & Paik, 2009)

After having sprint retrospectives in our team, I realized why they are important. The agile sprint retrospective is important because it helps in increasing the efficiency of agile by allowing the team to ensure continuous progress. After our team’s first sprint retrospective, we concluded that the manner in which we split the tasks was not effective and that we should do more planning in the next phase. The identification of hindrances allowed our team to function more effectively the following sprint. How and why does a retrospective help a team to increase its efficiency? Firstly, a retrospective helps the team to determine the amount of work required to accomplish the goal and develop a timeline for the project. Secondly, in this meeting the facilitator helps the team to generate discussions that help in determining what can be done to increase the functionality of the team. Such discussions also help in determining the root cause of problems that have occurred and identifying the factors that have contributed to successful completion of tasks. Finally, having a retrospective helps the team to celebrate their past achievements and be encouraged for future projects. (Kerth, 2001)

From my experience, I have realized a couple of important things about retrospectives that are worth noting. When we have had retrospectives, I have noted that sometimes our team members identify different issues as the root cause of problems. It is important that the team comes to an agreement about the root cause because that is the only way the team can rectify the issues. But, agreeing on something does not mean that the team should have only one vote and then impose the idea of the majority on the minority. Coming to an agreement is a long process that involves having a lot of interaction, discussing various issues and conducting multiple votes. During a few retrospectives, what has happened is that the team concludes that everything has worked perfectly in that sprint and that nothing needs to be changed. Although it is absolutely fine for a team to consider itself to be perfect, the team will not be able to improve itself if it does not identify the parts to improve. When there is a lack of discussion like this, these are some of the questions that have helped our team to identify the features to improve upon:

– Is our client happy with the way we interacted with him/her? Did we provide him/her with updates constantly?

– Was there any lack of coordination in our team? Did different team members request the same information from the client multiple times?

– Did we plan properly? Did we correctly set the sprint goals? Did we overestimate or underestimate any task?

– What was the most difficult issue that we have had to deal with this time? How can we avoid this issue the next time?

Our team’s template of a sprint retrospective report

These questions usually stir up a discussion and that is what is required in a retrospective! If there is only one opinion and everyone just agrees to that opinion, the team will fail to identify the obstacles to its success. Our team was able improve after every sprint and increase its efficiency because we were able to correctly identify the deterrents. As long as the retrospectives are held properly (by keeping the above points in mind), I believe that they will help in increasing the efficiency of the team to a great extent. The last thing to note is this – Kerth suggests that because every group has different dynamics, it is important to design the retrospective in a manner to fit the team’s culture and dynamics (2001). Hence, all the suggestions that I have made here might not work for your team. So, make sure you design your team’s retrospectives to suit your unique team!

In this post, we tried to understand what an agile sprint retrospective is and how it contributes to the efficiency of agile. We realized that agile retrospective meetings are extremely important because in retrospect the team can learn important lessons for their future. Although retrospectives might be difficult to design, if the retrospective is designed properly to suit to the team, the team will be able to see great results! In the next post, I am going to explain what agile task lists are and why they are important.

References

Derby, E., & Larsen, D. (2006). Leading retrospectives. In Agile retrospectives: Making good teams great. Raleigh, NC: Pragmatic Bookshelf. Retrieved September 26, 2014.

Hossain, E., Babar, M., & Paik, H. (2009). Using Scrum in global software development: A systematic literature review. 2009 Fourth IEEE International Conference on Global Software Engineering. Retrieved September 26, 2014, from http://www.cin.ufpe.br/~in1037/AllFinal/SE40%20Hossain%202009.pdf

Kerth, N. (2001). Engineering a retrospective: Making choices. In Project retrospectives: A handbook for team reviews. New York: Dorset House. Retrieved September 26, 2014.

Mahnic, V., & Zabkar, N. (2008, January 25). Measurement repository for Scrum-based software development process. 2nd WSEAS International Conference on Computer Engineering and Applications. Retrieved September 18, 2014, from http://www.wseas.us/e-library/conferences/2008/mexico/cea/1-%20CEA.pdf

Agile Retrospective image from http://agile-and-testing.chriss-baumann.de/2012/02/the-starfish-retrospective/

Retrospective second image from http://www.brighthubpm.com/agile/32098-iteration-retrospective-a-collaborative-performance-improvement-tool/#imgn_0