Agile Thoughts

by
This blog represents everything agile. Agile thoughts, issues, concerns, experiences, etc. I want to share and provide an outlet for the agile mindset. "Don't just do agile, be agile".

About this Blog

RSS

Recent Posts

Implementing Programs in Scrum

Regression Testing in Scrum

Planning for Uncertainty

Task Estimation with Scrum

Scrum Guidance Body Recommendations

Metrics and Measuring Techniques in the Retrospective Meeting

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:

  1. What are the things that the Scrum team needs to continue doing?
  2. What are the things that the Scrum team needs to start doing?
  3. What are the things that the Scrum team need to stop doing?

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.

Metric

Description

  1. Velocity

The number of story points completed in a specific Sprint.

 

  1. Completed Success Rate

The percentage of story points that have been completed compared to the commitment made by the team.

 

  1. Estimation Accuracy

The number or percentage of variations between projected and actual time spent on tasks and user stories.

 

  1. Feedback Ratings

The feedback obtained from stakeholders using subjective or objective ratings and providing a measurement of team performance.

 

  1. Team Morale Ratings

The outcomes from self-assessments concerning team member morale levels.

 

  1. Peer Feedback

The methods used to obtain constructive feedback to provide understanding about team performance.

 

  1. Release Progress

The business value provided in each release that increases the motivation levels of the team and work satisfaction.

 

Table 1. Retrospective Metrics

Velocity

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.

 

  • Team A has completed the following number of story points during the Sprints:
    • Sprint 1 – 15 story points
    • Sprint 2 – 16 story points
    • Sprint 3 – 20 story points
    • Average of Sprints 1,2,3 = 15+16+20 = 51/3 = 17 is the velocity
  • Story Points Remaining / Velocity = Number of Iterations Remaining
  • 150/17 = 8.82 = 9
  • It will take 9 Sprints to complete 150 story points based on the team’s projected velocity of 8.82

 

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%.

 

Estimation Accuracy

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.

 

Feedback Ratings

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:

  • 1 = Outstanding (A)
  • 2 = Very Good (B)
  • 3 = Good (C)
  • 4 = Fair (D)
  • 5 = Poor (F)

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:

  • Team Member 1 morale = High
  • Team Member 2 morale = Low
  • Team Member 3 morale = High

 

Peer Feedback

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.

 

Release Progress

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

 

References:

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

Posted on: September 09, 2018 12:12 AM | Permalink | Comments (9)

Impediment Logs in Scrum

Categories: Agile, Impediments, Scrum

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.

Impediment Types

  • Sick Scrum Team member
  • Slow Agile/Scrum adoption
  • Too cold team room
  • Process issues
  • Business or customer issues
  • Cultural or waterfall issues
  • People issues
  • Blockers for a User Story
  • Unresolved dependencies
  • Faulty equipment

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:

  • Impediments that are identified daily are generally very small and can be quickly resolved. This may include sending a simplifying email and/or getting assistance from a Scrum Team member.
  • The bigger impediments are most likely to be identified during the Retrospective meetings and require a level of dedication to be removed. These types of impediments are added to the Sprints for resolution.
  • Impediments that are identified by the team are added to the Product Backlog for prioritization and processing. Large items that are not able to be addressed quickly are addressed in later Sprints.
  • Organizational impediments added to the Impediments Log are prioritized and addressed on an ongoing basis. Both team and organizational impediments are reviewed after each Sprint in the Retrospective meeting.

There are two main types of impediments, organizational and team related and they need different types of handling.

  • Team Impediments – issues that the team can solve without needing external assistance. However, the team may need internal assistance from management. These types of impediments would include but are not limited to:
    • Changes to the way that the team works
    • Reminders for when a specific problem re-occurs
    • The need for tools or workflows that can make team’s work easier
    • Internal measures put in place for the team to avoid repeating a prior error
  • Organizational Impediments – issues that are dependent on others to solve. These issues include but are not limited to:
    • Slow internet
    • Issues with obtaining input from other teams or divisions
    • Lack of training

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.

Impediment Logs

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.

Process

Description

  1. Record

The Daily Standup Meeting is the best time to document impediments in the Impediments Log as each team member reveals them. After the brief meeting, the Scrum Master will gather additional information so that the impediments can be prioritized.

 

  1. Prioritize

Impediments should be prioritized based on their levels of importance and in relation to those on that are already on the log.

 

  1. Publish

The Impediments Log should be made visible to everyone and posted for all to view.

 

  1. Address

The Scrum Master should address the highest priority impediments from the log and ensure that it is removed so that the team can continue to reach the Sprint’s objective.

 

  1. Communicate

When the impediment is removed, this information should be communicated to the involved parties and the Impediments Log is updated.

 

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.

Impediments Log Field

Description

  1. Impediment Description
  • Identifies what the impediment is

 

  1. Importance of Impediment Resolution

 

  • (Blocker, Critical, Major, Minor), Describes the priority level

 

  1. Action suggested to be taken

 

  • Recommended action to be taken to resolve the impediment

 

  1. Owner
  • The person assigned to remove the impediment
  1. Due date of when it must be resolved

 

  • Deadline date for resolution
  1. Release that impediment was identified in
  • Release number

 

Table 3. Impediment Log Data Input Fields

Figure 1. Impediments Log

Tips for Removing Impediments

Following are several tips for the removal of impediments:

  • Impediments should be identified at any time. The Scrum Team should never wait until the Daily Scrum to discuss them.
  • If an item will prevent the team from achieving the Sprint Goals, it’s an impediment.
  • There is a distinct difference between blockers and impediments. A blocker impacts a single task and an impediment hinders overall progress.
  • Use an Impediments Board to ensure of adequate transparency. This means that Impediments should be included in the list of Information Radiators.
  • Track completed impediments. This information is good feedback for the Sprint Review and Retrospective meetings.
  • The Scrum Master needs to understand the organizational culture to best figure out how to remove impediments.
  • Use courage and creativity to remove impediments. Ask for forgiveness later if a bold decision needs to be made.
  • Collaborate with the Product Owner. Many impediments in Scrum are related to product management, stakeholder and supplier collaboration.
  • Don’t waste time and effort in fixing incorrect problem. Make sure that the focus is on the real problem(s).

Keywords: Impediments, Logs, Scrum

References:

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/

Posted on: September 08, 2018 11:57 PM | Permalink | Comments (10)

Scrum and Kanban Boards

Categories: Scrum

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 “Story” column identifies the user story that is ready to be worked on by the development team.
  • The “To Do” column represents tasks that need to be completed.
  • The “Work in Process” column represents tasks that are currently being worked on.
  • The “To Verify” column represents tasks that need to be verified and tested.
  • The “Done” column represents completed tasks.

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:

  • Scrum limits WIP per Sprint. The Scrum team can have unlimited items in the “In Progress” column.
  • Kanban limits WIP per workflow status (Ready, Kick-Off, In Progress, Review, Accepted). A number in the “status” sections means that the maximum number of items cannot be greater than that number. Figure 2. Shows an example of limits on the Kanban board. Observe that the Kick-Off Column has 1 as its limit, In Progress has a 3, and Review has a 2.

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.

Team Utilization                  

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:

  • New Features
  • Tasks
  • Defects
  • Change Requests
  • Technical Requirements
  • Knowledge Attainment

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.

Physical Boards

Virtual Boards

  • Forces co-location and face-to-face communication.
  • A geographically disbursed team can work seamlessly together and the Scrum Board is always visible to everyone at any time from any place.
  • The discipline needed to create consistent cards with the relevant information is easier to accomplish.
  • The virtual board has much more customization options that can be matched to needs of a business.
  • Ease in changing the process workflow.
  • More ease with workflow analysis and report preparation.
  • Physical boards create focal point for daily stand-up meetings.
  • Historical data is readily available.
  • Physical cards have space limitations.
  • Virtual cards have greater information capacity.

Table 1. Virtual and Physical Scrum Boards Comparison

Keywords: scrum, board, teams

References:

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/

 

 

 

Posted on: March 05, 2018 08:43 PM | Permalink | Comments (10)
ADVERTISEMENTS

I think somebody should come up with a way to breed a very large shrimp. That way, you could ride him, then, after you camped at night, you could eat him. How about it, science?

- Jack Handey

ADVERTISEMENT

Sponsors