Month: September 2014

What is an Agile Sprint Retrospective?

Practice makes perfect has been a quote many of us have all heard. However, what if what we have been practice is flawed. The end result would be a disastrous result rather than perfect. As Vince Lombardi once said, “Perfect practice makes perfect”. Reflection is the first step of achieving “perfect”. Sprint Retrospectives are meetings in which Scrum Teams reflect on themselves and their work, producing an actionable plan for improving. Sprint Retrospectives are the final event in each Sprint, marking the end of each Sprint cycle (Starr, 2012). They provide an opportunity to grow and to better understand the project in general. Agile sprint retrospectives are extremely important and may be the most important step of the entire sprint process.

Standing up during Sprint meetings fosters more activity.

Some individuals see retrospectives as a waste of time and wonder why conduct the retrospective in the first place? Shirly Ronen-Harel puts it best when explaining the positive aspects of the session. “Each team member sees things differently, if we wish to improve as a team we need to get everyone’s opinion to the context of the team. Without a retrospective session, the team will probably continue to make the same mistakes all over again… and the rate of improvement will be lower than it can get” (Ronen-Harel, 2013). Agile is all about maximizing each team member’s strengths.

Agile was created as an improvement to the bulkier style of Waterfall and Code-and-fix. A large problem with them is that they don’t provide opportunities for small scale growth and improvement. Once a portion of the project is finished in Waterfall, the team is unable to go back and review what could be improved upon; they must continue on with the project. “The majority of feedback for the Sprint Retrospective confirmed that teams use this activity to make tactical decisions about process, specifically around short-term improvements” (Drury et al., 2011, p.44). These retrospectives are a key part of what sets agile apart from the other development methods.

The bare-bones purpose of the retrospective is an elaborated pros and deltas overviews of the recent sprint, including what worked well, and what could be improved upon. Scrum masters are involved in these meetings to overview what is discussed between the group and give input on what would best benefit the team.

Start, Stop, and Continue.

A general guideline when conducting sprint retrospectives is the simple three-step method of Start, Stop, and Continue. Start refers to what to start doing in the next sprint. This may include something as obvious as unresponsive members communicating more. Stop is what you think it is; it refers to what to stop doing in the next sprint. Finally, continue is what has been working well. Keep doing whatever it is, because it will lead to a better final product.

Drury, M., Conboy, K., & Power, K. (2011). Decision Making in Agile Development. 2011 Agile Conference, 39-47.  Retrieved from

Ronen-Harel, S. (2013). The Retrospective Session for Everyone. Agile Coaching for Everyone. Retrieved from

Starr, D. (2013). Effective Sprint Retrospectives. Microsoft Developer Network. Retrieved from

Image credit to:

The Agile Team and what is a Backlog? What are they for and why are they important?

The Agile Team

Software development is a team effort. An agile team focuses on utilizing everyone’s individual strengths to collaborate and grow an even better product. According to Blackburn and Highsmith, “A project is built from people having differing personalities and differing skills… The people, environment, and organizational culture all influence one another” (Blackburn and Highsmith, 2001, p. 133). Not every person is the same and has their own set of unique personalities. This is what agile thrives on and ultimately creates a more polished product.

A large difference between agile and other team development methods (not just computer technology, but business and other fields also), is that agile focuses on members continually working together in person. “The agile team works to place people physically closer, replace documents with talking in person and at whiteboards, and improve the team’s amicability” (Blackburn and Highsmith, 2001, p.131).

This team effort is comprised of many different roles. The most important of these roles include the product owner and the Scrum master. As we have gone over before, the product owner is the primary stakeholder. They create the user stories, and is responsible for input in the product backlog. The scrum master is similar to, in business terms, a product manager. They are the main link between the product owner and the agile teams. Their primary objective is to make sure everything is running smoothly with the agile team, and do everything within their power to facilitate team progress. The agile manifesto says it best, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” (Beck et. al., 2009, p. 6).


The Product Backlog

Scrum Task Board

Figure 1

A product backlog (Figure 1) is a collection of ideas that the stakeholders desire in the final product. However, not everything can be materialized, so the team looks through the backlog to see what can be done. Not everything is worked on at the same time. This is when the team utilizes Sprints to tackle smaller groups of problems. These backlogs are useful for progression, as teams as can create burndown charts. These charts track how much work still needs to be done and time. By utilizing these charts, the teams can estimate when the product will be finished and whether it will be done before the deadline. Refer to Figure 2 on an example of how these charts work. The actual burndown indicates actual progress, whereas the blue indicate the ideal progress. The numbers indicate how many hours of workload are left.

Figure 2


By using a burndown chart, agile members can figure out what in the backlog is taking up a lot of time to complete and needs to be focused on.




Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … & Thomas, D. (2001). Manifesto for agile software development. Retrieved from

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

Ingalls, L. (2010). Scrum task board. Licensed under Creative Commons Attribution 2.0 via Wikimedia Commons . Retrieved from

TechBudha. Create a burn down chart using Excel in less than 5 min. Retrieved from

What is Agile and What are User Stories?

Software projects requires some sort of cohesive team effort, but where can you start? Different methods have been created by developers on creating software on a timeline, such as Code-and-fix, Waterfall, and Agile. Code-and-fix was one of the first methods of development of software. The method was fairly ineffective; when problems arose from coding or there was a difference in vision from what the product owner wanted, it required a large amount of time and resources to remedy. Waterfall was a step in a better direction. The method created specific modules for development and testing. However, Waterfall was still not entirely a foolproof system for code development. Once a team completed a module, it was difficult to revert and change problems that originated from the previous module.

Waterfall (Left), Agile (Right).

Agile utilizes a cycle method, also known as Sprints, which focuses on improving the product frequently while collaborating with the product owner specifying what works and what doesn’t. A major difference between Agile and other methods is flexibility on requirements. As development continues, the product owner may need to alter a feature, and add an entirely new feature that was not originally  on the blueprint. User stories are the product owner’s wishes on features of the finished software. Agile developers read these user stories and determine what can and cannot be put into the final product. This has been regarded as an easy way to find out what people want in their product while being concise. After user stories have been collected, the developers can use a technique called “Planning Poker” in order to figure out what should and should not be worked on for the Sprints.

User Stories Template

From the article, “What Agile Teams think of Agile Principles”, by Laurie Williams, she reviews over two surveys conducted on how effective agile practices are and the most important futures of agile.  A large amount of those surveyed put importance on satisfying customers first and foremost. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”(Williams, 2012, p. 73). The absence of updates and seeing software development in progress was a large fault of Code-and-Fix, and Waterfall. Adil Zeaaraoui states in “User Stories Template for Object-Oriented Applications”, “They help bridge the developer-customer communication gap; they provide the common language to build understanding between the user and the technical team” (Zeaaraoui, 2013, p. 408). A large problem in most teams is communication. The translation between from technical language to consumer-friendly language can be rough, but can be fixed through these user stories.


Williams, L.. (April 2012). What Agile Teams think of Agile Practices. Communications of the ACM, Vol. 55. Retrieved from

Zeaaraoui, A., Bougroun, Z., Belkasmi, M., & Bouchentouf, T. (August 2013). User Stories Template for Object-Oriented Applications. Third International Conference on Innovative Computing Technology. Retrieved from

Image credit to

Image credit to