The Sprint Retrospective: A Time For Critique And Praise

Thumbs-Up-and-DownI have already stressed numerous times already that Agile contains many mechanisms that stress the importance of flexibility and change. One of these mechanisms, the sprint retrospective, is worth looking into a little more deeply due to the positive impact it has upon the development processes.

In essence, the sprint retrospective is a time for the team to identify things from the previous sprint that are either less than ideal and need to be improved or that are good and should be done more often. A time for constructive critique and praise in order to improve the productivity and results of the next sprint. Chris Mann and Frank Maurer have done an extensive study on opinions regarding the Agile process as a whole and found that the sprint retrospective is generally given praise by developers that utilize the Agile methodology. However, Mann and Maurer found in their study that there is one critique that the developers have regarding the conciseness of the meeting: They often find that the client, scrum master, and project-manager tend to be under-prepared for the meeting and veer off the topic, which causes meetings to drag on. I feel that I must second this critique as someone who works in software testing. Meetings with developers and project managers tend to get sidetracked when the two go off on long tangents discussing possible features they can add to the software in future versions, I find it necessary to reel them back into the primary discussion topic from time to time, a relatively simple fix to the issue.

Something people new to agile tend to get confused about is what kind of topics should be discussed during the sprint retrospective. Allow me to clarify this for the reader; the retrospective is all about the details of the process itself that need to be improved rather than features and bugs, those topics are reserved for the preceding the sprint review. A good example of such a topic is found in Mann and Maurer’s study; during one of the retrospective meetings the clients and developers agreed that they would no longer do extended sprints when they found that they needed more time to complete a task. They’re rationale for this was that the developers would end up not knowing what they needed to do and they agreed to instead either trim down the work or move it to the next sprint.

Once again we can see that agile gives developers a way to refine the process by which they create quality software and optimize their productivity. Critique and praise of the processes being used is important, not all teams function identically and it is therefore important to be critical of what processes are working in any given project. The retrospective is the time for teams to facilitate this critique at the end of each meeting.



Mahnic, V. (2011). A Case Study on Agile Estimating and Planning using Scrum. Electronics and Electrical

Engineering, 5(111), 123-128. Retrieved September 29, 2014, from


Mann, C., & Maurer, F. (2005). A Case Study on the Impact of Scrum on Overtime and Customer Satisfaction. Agile

Conference, 2005. Proceedings, 70-79. Retrieved September 28, 2014, from

Retrospective Table [Image]. (2013). Retrieved Sepetember 28, 2014,


Thumbs Up & Down [Image]. (2013). Retrieved Sepetember 28, 2014, from:



What makes the your team so important? And what is the backlog?

Volumes were spoken about the features that make agile what it is in my previous entry. In this entry I will explore two of these features more in-depth; the team and the backlog.

Let’s start with the team, the true muscle of the project. Agile has lots of rules and processes for promoting productivity and camaraderie in a team. However, agile can only do so much for the individuals in your team. It is ultimately the team that makes the product, not agile nor an individual in the team. Alistair Cockburn and Jim Highsmith found in their study that where developers lacking skill and experience fail, a team of developers working together will fare far better than the former. They say that this is due to things like good communication and interaction. With that in mind, one must bring people together who can communicate with each other and interact well with each other in order to fully utilize the benefits of agile, it cannot be implemented into just any team and expected to improve their throughput. Although that doesn’t mean agile isn’t flexible enough be compatible with different teams; Cockburn and Highsmith also point out that agile is designed to capitalize on the unique strengths of the individuals on the team where other processes standardize the process to each team.

The team’s morale is another important factor identified by Cockburn and Highsmith; they cited a study that concluded agile methodologies score higher than others in terms of employee morale and deliver an even better product. The promotion of close interaction, daily scrum meetings, and meetings with the clients are all factors that bring the parties involved on the project closer together which, not only improves communication, but also improves the team morale by having them know each other on a more personal level.

The next major feature I want to talk about is the backlog. The backlog is essentially a prioritized to-do list usually populated by user stories, features to implement, bugs to fix, or things to change. The nice thing about the backlog is that, only a select few high priority items are selected to be developed in each sprint and they’re locked in. Ideally, so that the client cannot reach into the backlog mid-sprint and tell you they want something else implemented. This isn’t to say that the client can’t make changes to work that has been done, they just have to wait until the current goal has been finished. That way the developers don’t get reallocated or sidetracked mid-development from some feature and the client is more likely to have a tangible product to assess at the end of the sprint. Yet another part of agile geared towards keeping everyone happy and promoting teamwork!


Backlog Pyramid [Image]. (2012). Retrieved Sepetember 21, 2014,



Cockburn, A., & Highsmith, J. (2001). Agile software development, the people factor. Computer, 34(11), 131-133.

Retrieved September 21, 2014 from


Keith, C. (2006). Agile Methodology in Game Development: Year 3 [Powerpoint slides]. Retrieved September 21,

2014 from:

Team[Image]. (2012). Retrieved Sepetember 21, 2014, from:

What is Agile and what are user stories?

(Agile, 2012)

At first glance, Agile is a methodology in which a costumer specifies requirements and the development team creates these requirements in numerous iterative cycles. Between each iteration the team and costumer meet to evaluate a tangible product and determine whether or not changes need to be made to the requirements.

A key feature of the Agile methodology is the ability of the development team to work closely with the customer. Agile facilitates this close interaction via “user stories.” Agile utilizes user stories in order to envision a feature or requirement of a product from the point of view of the costumer, user stories hone in on the customer’s requirements rather than attempting to nail down every detail. The tiny details of how a requirement functions are susceptible to a great deal of change as the costumer sees this system start to come to life, Agile is designed to handle this change. As Laurie Williams, head of a Software Engineering Research group at NCSU, points out: the costumer prioritizes a number of these user stories to be the target of a release plan and the team then begins the process of iterating through development cycles, or Sprints as they are formally known.

Sprints are another key feature of Agile. Dividing up the development process into pieces, based on the priority of user stories, gives the team and the customer opportunities throughout the project to re-evaluate any and all aspects of the software in order to determine if the user stories and/or release plan need to be modified. Between the planned Sprints the team and the customer can meet and evaluate the current state of the product. Based on this evaluation, the costumer and team can take a number of actions such as modifying, adding, or re-prioritizing requirements. According to Williams, this ability to deliver function software and prioritizing them is credited as being the largest success factor when developing software with the Agile methodology.

(Agile Method, 2013)

In a sequential development approach the development teams only have one chance to accomplish each goal, sequential methodologies work under the assumption that all software requirements can be foreseen at the start. This is what gives Agile an edge: the methodology is designed with the intent of creating functional, but not necessarily ready-to-ship, products at the end of each Sprint so that the team and costumer can meet and re-evaluate the needs of the product based on tangible software rather than theoretical ideas. At the start of a project, the costumer could have a reasonable idea of what they want out of the product. However, as software developers, we know all too well that the initial vision of a software product can crumble in a moment’s notice due to an unforeseen detail and that is why the Agile methodology exists; to provide a flexible system that can deal with change and keep the project on track.



Agile[Image]. (2012). Retrieved Sepetember 14, 2014, from:

Agile Method[Image]. (2013). Retrieved Sepetember 14, 2014, from:


Chow, T., & Cao, D. (2007). A Survey Study Of Critical Success Factors In Agile Software Projects. Journal of Systems and Software, 81, 961-971. Retrieved September 15, 2014, from


Williams, L., & Cockburn, A. (2003). Agile software development: It’s about feedback and change. Computer, 36(6), 39-43. (2003, June). Retrieved September 15, 2014, from