Sample Case Study Paper on Agile and Sprint Retrospectives


Various corporations’ approaches to project management have been significantly influenced by PMI’s PMBOK approaches, Agile PM and Agile approaches. They have also been influenced by Scrum Sense’s approaches, concepts, best practices, approaches of various Agile Manifesto signers and Agile PM luminaries. This paper looks at Agile and Sprint Retrospectives based on four videos and its relation to the XYZ Corporation.

Video One – ‘Agile in Practice: Retrospectives after Iteration’

This video is an Agile in practice talk. The presentation indicates how teams do work in a type of experience called iteration. Working this way allows a team to pause regularly and reflect on their working together, how to make improvements to identify the issues that need clarification. The Agile retrospective is based on facilitated by Agile coaches to ensure the teams work in atmospheres of utmost trust. This means all information; feelings and things can be expressed if everyone gets a chance to speak. In these talks, we found out how the meetings are run in what benefits agile teams get from them. They invite an Agile coach facilitator to be involved in seeing the team having its retrospectives after a significant event. After the release, teams start on a low release before starting on the next one. There are various questions to be answered in a group in a retrospective. The first is what worked well, what didn’t work well and what still puzzles members. There concepts outside the video that are vital to XYZ Corporation. Successful adoption of agile practices is crucial despite organizations being   heavily waterfall-centric (Cohn & Ford2003).The pockets of innovation emerge through bottom up endeavors often instigated by focused small teams and focused individuals who are quick to discover the local benefits offered through such practices.

Video Two – ‘The wrong way to do Agile Retrospectives’

Retrospectives are often done wrong in various ways. The starting is by identifying the scapegoat, by identifying the weakest member to make the others feel better about them. The other way is failing to acknowledge the significance of dialogue in a retrospective and the members never worrying about any of the happenings. The other wrong will be members failing to keep the team discussions records for future, destroying the documents as a way of ensuring that nobody ever learns from it. The other wrong is failing to learn from retrospectives. There are various right things to do in regards to the wrongs in relation to the XYZ Agile environment. The first right thing to do is encourage every member to improve on their weak areas by assigning each a stronger booster member. The other right thing is to uphold constructive and all member inclusive communications (Derby, 2006). The other right way   is to have interference free data base for all the team’s documents and to always learn from retrospectives.

Video Three – ‘How to improve your Scrum Sprint Retrospectives’

Retrospectives are meetings which focus on improvements. The first is by assessing the team’s work and identifying what is to be done to bring out the expert in the members. There are various mistakes done in the scum sprint and retrospective improvements. The first is a boring retrospective when one retrospective technique is used over and over again. It is difficult to engage a team if they are bored. The other mistake is failing on the improvements on previous failures. This occurs when teams define too many non-actionable improvements to be implemented and leaving them untouched. The third mistake is about teams complaining and not searching for improvements that can be implemented. There are various tips to improving on the mistakes such as varying with formats, locations and never compromising. The other is  taking one action step by step with a focus on improving. The other is defining a retrospective goal. This focuses on ideas to be improved directly. The other is involving management by letting them to be part of the team’s problem solving. The last is removing tables by being actionable to bring value in making things better. The tip i think is most important for XYZ Corporation is involving management by letting them to be part of the team’s problem solving. I think the least important tip for XYZ Corporation is defining a retrospective goal. An additional tip not included in the video that we want to nonetheless emphasize at XYZ Corporation is allowing the teams to determine their Sprint capacity (Hoda 2010).

Video Four – ‘Inside the Sprint Retrospective’

People get together to discuss how the team went wrong. They remember accounts of what went wrong, what they liked, and keep figuring on how to go about making the improvements. Based on the training, the team will then come up with a process of improving, prioritizing, training and strengthening systems as websites that are too slow. The team also identifies major problems and fixing items with big impacts. It also commits to getting the identified problems fixed as a way of enhancing team acceleration. If not identified and fixed ideally before the next retrospective, it would be a complete waste of time. There are various elements the team should keep. It should keep track of previous retrospectives and review results (Cohn & Ford2003).The team acceleration would produce quality improvements .It should also keep in mind a prioritized action on   items. It should also keep a working plan for the retrospective. This clearly indicates the significance of retrospectives in improving a team’s performance.


Derby, E., Larsen, D., & Schwaber, K. (2006). Agile retrospectives: Making good teams great (p. 200). Raleigh: Pragmatic Bookshelf.

Cohn, M., & Ford, D. (2003). Introducing an agile process to an organization.Computer36(6), 74-78.

Hoda, R., Noble, J., & Marshall, S. (2010, May). Balancing acts: walking the Agile tightrope. In Proceedings of the 2010 ICSE Workshop on Cooperative and Human Aspects of Software Engineering (pp. 5-12). ACM.