A retrospective is a time-boxed ceremony where the Core Scrum Team (optional for the Product Owner) convenes to discuss the iteration that was most recently completed. This practice is very similar to the lessons learned meeting that takes place in waterfall projects. Pertinent information is collected during these meetings and is documented for utilization in future Sprints. Scrum Team members discuss their existing best practices, potential improvements, issues and blockages. The Scrum Master ensures that the high priority recommendations are implemented not later than the next Sprint.
The retrospective is an Inspect and Adapt event that is facilitated by the Scrum Master. Discussions, based on what went right and what went wrong, are recorded for imminent accomplishment. Participation by all team members is expected. The main goals of the retrospective are to provide responses for three distinct assessments:
Metrics and Measuring Techniques
There are a variety of metrics that a Scrum team can utilize to measure their performance on a Sprint by Sprint basis. These metrics have been identified in Table 1. below.
Table 1. Retrospective Metrics
Velocity is a number that stands for the average number of user stories that have been completed during the Sprints. When a Scrum team has determined the average number of story points that they can complete, they can then calculate the estimated time frame that it will take to finish the project. The team will use the number of user stories that need to be completed and then divide this number among the remaining Sprints. For example, if a team has a total of 150 story points remaining, then the projection for completion is then 9. This assumes that the average velocity has been averaged at 17 story points per Sprint.
Completed Success Rate
This metric is represented as a percentage of the story points completed based on what the team projected that they would complete. For example, if the team made a commitment to complete 50 story points and they only completed 49, the completed success rate would be 49/50 = 98%.
This metric is represented as a percentage of the actual time spent on tasks and user stories and the time that the team estimated would be needed. For example, if the team estimated their total work as 50 hours and it took 45 hours to complete, then 45/50 = 90% estimation accuracy.
This metric is the feedback rating from the stakeholders on the project using subjective and/or objective ratings that measures the Scrum Team’s performance. For example, stakeholder may provide feedback as “Very Good, Excellent, or Outstanding”. This would be an subjective measurement of feedback. On the other hand, if a stakeholder responds on a scale of 1 to 5, where:
The above measurement represents an objective feedback rating.
Team Morale Ratings
The Scrum Team members conduct self-assessments regarding their morale in relationship to the project. For example, team members provide information such as:
This metric is used to provide feedback for Scrum team members where each team member choses a peer, conducts observation during an agreed upon time frame and then share the information to the selected peer. With Scrum, other members of the Core Scrum Team can participate in peer feedback (Scrum Master, Product Owner). Some firms use the 360-degree feedback model, a many-to-many feedback format. This model focuses on team member performance evaluation and a questionnaire is typically used. This model has little to no team collaboration.
This metric is based on the amount of business value that is provided in each release based on story points. A Release Burnup Chart is used to identify the work completed for the release. A business uses this metric to determine how much work has been delivered. Burndown Charts can also be used for this metric. See Figure 1. below.
Figure 1. Release Burnup Chart (Agile Velocity Blog, 2014)
In conclusion, companies have their organizational specific measurement techniques and metrics. The metrics presented here are just examples used during the Retrospective meetings and the choice of which ones to use are based on the project’s needs.
Keywords: retrospective, metrics, measurements
Agile Alliance. (2015). Glossary. Velocity. Retrieved from https://www.agilealliance.org/glossary/velocity/
Agile Alliance. (2015). Peer Feedback. Retrieved from https://www.scrumalliance.org/community/articles/2015/january/new-innovation-to-scrum-ceremonies-peer-feedback
Agile Velocity Blog. (2014). Improve Your Visibility into Release Progress. Retrieved from http://www.agilevelocity.com/blog/release-planning/
SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition
Impediments are barricades, hurdles or obstacles. In terms of Scrum, they are “blockers” that prevent the Scrum Team from completing work, which in return impacts velocity. Anything that prohibits the team from doing work is considered an impediment. Examples of Scrum impediments are listed in Table 1.
Table 1. Scrum Impediments
The Scrum Master is responsible for tracking, monitoring and ensuring that impediments are removed. All Scrum Team members are responsible for continually identifying impediments for discussion during the Daily Standup Meeting. If for some reason an impediment does not disappear in a timely manner, this would indicate that the root causes have not been identified. The Sprint Retrospective is another place for impediments that reoccur. It is important to understand that the Scrum Master is not solely responsible for the removal of impediments. The team should work together to remove impediments that can be easily resolved and provide assistance with any additional support that may be required.
A few things to note:
There are two main types of impediments, organizational and team related and they need different types of handling.
The expectation is that the team can learn to remove its own impediments without the Scrum Master’s intervention. This also means that impediments in the log should not be delegated to the team because many of them may be very difficult to resolve. On the other hand, the Scrum Master is not expected to resolve all impediments alone either. The entire Scrum Team needs to work together to determine which impediments it can resolve and what support may be needed. Over time, the team should become capable of removing more and more impediments on its own.
There should only be a single Impediment Log for a Scrum Master to manage. Table 2. outlines the process that is typically used to create, monitor and maintain the Impediments Log.
Table 2. Impediments Process in Scrum
Table 3. identifies a description of each of the field on the Log. Figure 1. is an illustration of an Impediments Log. Let’s examine the data input fields to gain the proper understanding of their usage.
Table 3. Impediment Log Data Input Fields
Figure 1. Impediments Log
Tips for Removing Impediments
Following are several tips for the removal of impediments:
Keywords: Impediments, Logs, Scrum
CoreWorks. (2014). The Impediments Backlog. Retrieved from http://www.coreworks.co/scrum-impediments-backlog
Getting Agile. (2011). Organizational Impediment Management: Early Risk Detection for Agile. Retrieved from http://www.gettingagile.com/2011/01/24/organizational-impediment-management-early-risk-detection-for-agile/
LeanAgileTraining. (2017). What are Impediments? Retrieved from https://www.leanagiletraining.com/impediments/what-are-impediments/
Openbravo wiki. (2009). Scrum/Impediment. Retrieved from http://wiki.openbravo.com/wiki/Scrum/Impediment
Overeem, Barry. (2016). The Scrum Master as an Impediment Remover. Retrieved from http://www.barryovereem.com/the-scrum-master-as-an-impediment-remover/
Scrum Alliance. (2011). Five Tips for Impediment Resolution With Scrum. Retrieved from https://www.scrumalliance.org/community/articles/2011/september/five-tips-for-impediment-resolution-with-scrum
scruminc. (2017). Impediments. Retrieved from https://www.scruminc.com/impediments/
Scrum and Kanban Boards
The Scrum Board is an important component of the Scrum methodology. This board is used by Agile teams to track their development work within time-boxed iterations called Sprints. The Scrum Board shows all backlog items that need to be completed within the current Sprint. Team members use the board by completing work and making updates continuously throughout each Sprint. Scrum team members typically make updates to the board daily because of progress made the previous day. The board’s layout consists of rows and columns, where each row contains user stories (units of work), and columns that show the status. Scrum boards provide a fast, simple view of the user stories selected for a Sprint that the development team is working on and have been completed. Figure 1. shows a typical Scrum Task Board used by the Scrum team.
Figure 1. Scrum Task Board
Every row on the Scrum board contains user stories that represent product backlog items that have been selected during Sprint Planning. Following is a description of the columns on the board:
The Kanban Board
The Scrum board, as well as the Kanban board, is used to show the progress of development work. Both boards are categorized as whiteboards in the “To Do-In Progress-Done” categories. The Kanban board is used to display the work process flow and the number of items in the work in progress (WIP) column. According to Lean concepts, WIP should be limited to where it is small enough to avoid wasteful tasks, but large enough to reduce the number of idle workers. In terms of WIP limits, the following applies:
Figure 2. Kanban Board with WIP Limits
Kanban vs. Scrum Board
With a Scrum board, the entire team is responsible for each task. With the Kanban board, the team is not responsible, but each person has responsibility for their step on the task flow (development, testing, verifying, etc.). If a team member has completed their task, that person can choose what to do by either helping another team member with their taskings or take on another activity from the queue. A Scrum board is used by one Scrum team whereas the Kanban board is a workflow that is not required to be owned by a specific team. The Product Owner should not be able to make changes to a Scrum board because of the team’s commitment to complete a specific number of user stories. The Scrum team members are the only parties that can make changes to the Scrum board. With Kanban, the Product Owner (or proxy such as Service Delivery Manager) can edit the Kanban board. The Scrum team should not add any new items to the Scrum board during a Sprint. Work items are set in stone during Sprint Planning before iterations begin. Kanban has no established time frame for making updates to its board because it has limits on the work in progress activities. When tasks are moved from the In-Progress column to the Done section, capacity is released and new work items goes to the Development queue.
In some cases, an Agile team may decide to add additional categories to their Scrum Boards that match their actual workflows. Most boards have a minimum of three categories: To Do, Work in Progress, and Done. The optional categories may be, for example, Testing or Verify columns. A virtual Scrum Board adds a lot of value to Product Owners and Scrum Masters can create metrics that help improve the Scrum team’s processes. Often, teams use a combination of physical and virtual boards to the relevant advantages of both. Additional categories that are used on Scrum boards include but are not limited to the following:
Physical vs. Virtual Boards
When a team is physically located in the same space, it’s better to use a physical Scrum Board. The board is better utilized when it is in a common area where the team can view and access it very easily. In some companies, this board is placed by the water fountain, a place where many people gather and communicate. This can result in a better collaborative work area. If a team is geographically dispersed, it would be better to use a virtual product such as for example, VersionOne, Rally or JIRA. Following is a comparison of physical and virtual Scrum Boards as shown in Table 1.
Table 1. Virtual and Physical Scrum Boards Comparison
Keywords: scrum, board, teams
Gunter, Stuart. (2012). Experimenting with Horizontal WIP Limits in Kanban. Retrieved from https://www.stuartgunter.org/posts/experimenting-horizontal-wip-limits-kanban/
Kanban Tool. (2017). Scrum Task Board: Apply Scrum Methodology with Kanban Tool. Retrieved from http://kanbantool.com/scrum-task-board
Mountain Goat Software. (2017). Scrum Task Board. Retrieved from https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/task-boards
RealtimeBoard, Inc. (2017). Scrum vs Kanban Boards: 11 Major Differences. Retrieved from https://realtimeboard.com/blog/scrum-kanban-boards-differences/#.WZsybSh97Zs
Scrum Inc. (2017). Scrum Board. Retrieved from https://www.scruminc.com/scrum-board/