Agile Thoughts

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.

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 (SBOK^TM Guide.), 3^rd 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:

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

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:

• 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/

Risk identification at the program and portfolio levels can be an extremely challenging activity. The main thought process about risk management at these levels is to share ownership at the project level with those at the program and portfolio levels. Probability and impact ratings vary at different levels and risk rarely occurs at a single level without affecting higher levels. When risk is identified at multiple levels, this constitutes a very high level of risk management complexity. 

Program Risk Management 

Risk at the program level include threats that are often present at the project level. Typically, risks are present in both existing and successive projects within a program. Quite often, these risks can be mitigated early with the same actions across a program. Program risks have the potential to have a cascading effect on projects within a program, resulting in more effort to resolve.  

A common viewpoint of the program manager is that a single project’s contribution has a very limited impact at the program level. The program manager often feels that the resolution to project related risk that impacts a program is best resolved by termination. In the case of a risky but critical project in a program, removal is not an option. Projects within a program have different levels of criticality and the overall level of acceptable risk is based on the organization’s risk tolerance level. 

Portfolio Risk Management 

Most companies measure risk from within an enterprise portfolio. Every program must examine each project to determine if the risk level is within an acceptable range. High risk often results in high returns and the lower the risk, the lower the expected return. It is important to create a balance of high and low risk projects and programs to provide the maximum amount of return. Effective risk management should be developed to incorporate and provide protection for the entire organization.  

Risk management at the portfolio level starts at the upper management level and should include all stakeholders. The process begins by taking an inventory of the ongoing projects. Leaders in the organization should define goals in terms of what should be accomplished. A predictable measure for risk at the portfolio level should be defined. Risks are categorized based on possible outcomes, impact and probability of occurrence. Many organizations use portfolio risk management software because it offers a framework for the establishment of communication requirements. Such tools are known to create a leveled playing field that excludes personalities, politics and favored projects.  

After the identification of portfolio risks, mitigation activities must be defined. Executives in the organization reviews all initiatives for elimination after the risk analysis process. The remaining group of initiatives for consideration are re-evaluated and re-prioritized with their mitigation strategies. The executive leaders will select the initiatives that will grow the company in the proper direction. Initiatives are then decomposed into projects. This begins the lifecycle of corporate initiatives and related projects. The takeaway from risk management at the portfolio level is that organizational cultures must value risk. In real life, change will undoubtedly occur and risk and opportunities can come to fruition quickly. It is beneficial for an organization to establish risk management at the enterprise level because of the following benefits:  

• Communication and participation is improved for all stakeholders 

• Improvements in corporate processes that propose and approve investments 

• Process transparency and consistency results in faster organizational consensus 

• Prioritization of investments provide savings based on the portfolio’s merit 

• Timely identification of programs and projects at risk 

• Release of funding needed to invest in new initiatives for business transformations 

• Lessons learned that add value to consistent refinement of the portfolio management process 

• Project management balance that optimizes business value for the entire portfolio 

Agile Risk Management 

On agile projects, all team members are responsible for the identification of risks that have the potential to impact development sprints, projects or programs. Scrum ceremonies provide the venue for risk identification on a regular basis. Risks are identified during the following Scrum encounters: 

• Daily Scrum  

• The main forum for risk and issue identification daily 

• Retrospectives  

• Risks can be uncovered during continuous improvement discussions 

• Requirements Analysis  

• The Product Owners leads requirement discussions for the purposes of maximining value and minimizing risks 

• Sprint Planning 

• During this meeting, the team identifies, evaluates and provides risk responses for identified risk 

• Sprint Review 

• Stakeholders are kept in the “know” and risk mitigation activities are discussed 

• Scrum of Scrums 

• Risks and issues are addressed at the team, project and program levels 

• Planning Poker 

• Story size estimation occurs and provides the opportunity for risk reduction by eliminating user stories that are too large and need to be broken down 

Figure 1. below outlines the Agile Risk Management process (Identify, Assess, Respond, Review). 

Figure 1. Agile Risk Management Process (Yegi, 2015) 

There are four ways to address risk in agile environments: 

1. Mitigate – An agile team implements risk mitigation by focusing on their velocity or capacity to develop the features tied to the user stories. They agree to the amount of work that they feel confident can be completed and nothing more. 

2. Avoid – Projects or components of a project are cancelled to avoid threats in their entirety. The product owner will remove or change stories to eliminate this type of risk. 

3. Contain – The agile team agrees to just “deal with” the low impact and probability risk when it occurs. 

4. Evade – No risk action is taken when it is evaded. This typically pertains to risks that have been determined to have very little impact on the objectives of the project. 

Risk management at any level adds value to the organization and this ultimately impacts profitability. Leaders can proactively manage expected variances in programs and portfolios with adequate risk mitigation strategies.  

Keywords: Risk, Programs, Portfolios 

References: 

Faris, R. K. & Patterson, D. (2007). Managing risk in the project portfolio. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute. Retrieved from http://www.pmi.org/learning/library/managing-risk-project-portfolio-7297 

Wideman, Max. (2015). How do Project Risks Impact Programs & Portfolios? Retrieved from http://www.maxwideman.com/musings/impact.htm 

Yegi, Sanni Babu. (2014). Risk and Issue Management in the Scrum Process. Retrieved from https://www.scrumalliance.org/community/articles/2014/april/risk-and-issue-management-in-scrum-process 

All projects are usually required to undertake a business justification process, and Scrum is not an exception. This practice is essential because it helps the business understand its options pertaining to change initiatives, new products or services and providing justification for undertaking a new project. The business justification process is also an enabler for the Product Owner to start the creation of the Prioritized Product Backlog for meeting the expectations of executives and shareholders.

The Importance of Business Justification

It is important to conduct the business justification process because the reasons why a project should be undertaken must be clear and factual. The justification for the project must be established prior to approval. It must be demonstrated that the project is viable and the justification process is the driver for all project evaluations. A business should never expend large amounts of funding at the beginning stage or for the project continued until the justification process has been conducted. To be clear, the business justification process should be implemented on a continuous basis; at the beginning, at established intervals throughout the project lifecycle and whenever a risk or issue presents itself. Table 1 outlines the factors that drive the business justification process.

Table 1: Business Justification Factors

The Business Justification Process

This justification process commences prior to the initiation of a project and is consistently validated throughout the lifecycle. Business justification is determined by means of the following three steps:

1. Present and Evaluate a Business Case - A project is generally evaluated and approved by the Product Owner. After approval, the project is documented and presented as a business case. Subsequently, the Product Owner creates a Project Vision Statement and obtains approval from executives and/or the project or program management board.

2. Justification of Continuous Value - After decision makers have approved the Project Vision Statement, it is baselined and delineates the business justification. The business rationalization is continuously validated during the entire project execution stage and at predefined milestones. During the project, the Product Owner should regularly make certain that the Project Vision Statement is updated with the appropriate information to reliably empower decision makers to continue to make up-to-date decisions.

3. Benefits Realization Confirmation – The Product Owner has the responsibility to confirm the realization of customer benefits throughout the project and when the User Stories in the Prioritized Product Backlog have been developed and accepted.

Business Justification Contributors

The Product Owner is held being accountable for directing the activities that substantiate and keep track of business value for their assigned projects, programs or portfolios. In addition to the Product Owner, there are additional parties that provide contributions to the fulfillment of business justification activities such as:

• The Sponsor – provides the required funding for the project and monitors the project to validate the realization of its benefits

• Customers and Users – participates in defining the prioritized list of requirements and User Stories in the Prioritized Product Backlog. They also review product deliverables during each Sprint and Release and provide confirmation that benefits have been realized.

• The Scrum Guidance Body – possibly provide recommendations and guidelines that pertain to business justification techniques and the confirmation of benefits realization.

• The Scrum Master – facilitates the development of the project’s deliverables, manages risks and changes, and removes impediments. Collaborates with the Scrum Team, Product Owner and stakeholders to ensure that project benefits are realized.

• The Scrum Team – completes the deliverables for the project and contributes to the realization of business value.

Business Justification Calculations

There are many tools that can be used to evaluate and review projects during the business justification process. We focus our discussion on calculating the Project Value Estimation. Expected business value can be estimated using several methods such as Return on Investment (ROI), Net Present Value (NPV) and the Internal Rate of Return (IRR). Following is a synopsis of these three methods.

1. Return on Investment (ROI) – This calculation is used to justify a project by assessing the expected net income to be returned from a project after deducting the costs and then dividing by the total project cost. Using ROI, project value is calculated with the following formula:

1. ROI = (Project Revenue – Project Cost)/Project Cost
2. Example: With a project cost $2,000,000 to develop, expected financial benefits estimated at $5,000,000, ROI is determined as follows:
3. ROI = ($5,000,000 - $2,000,000) / $2,000,000) = 1.5
4. ROI is 1.5 times the initial investment (or 150%)

2. Net Present Value (NPV) – This calculation is used to figure out the current net value of future benefits with a presumed interest rate. NPV is the total expected income from a project minus the total cost of the project, considering the time-value of money.
   1. We are trying to decide between two projects:
   2. Project 1 has an NPV of $8,000 and its life cycle is 5 years
   3. Project 2 has a NPV of $5,000 and its life cycle is 2 years
   4. Project 1 has a higher NPV and we are considering the present value and NOT the future value.

3. Internal Rate of Return (IRR) – This calculation is a discount rate on the investment where the present value of cash inflows is made equivalent to the present value of cash outflows for determining a project’s rate of return.
   1. We are trying to decide between two projects to take on.
   2. Project 3 has an IRR of 5% and will be done in 4 years
   3. Project 4 has an IRR of 15% and will be done in 2 years
   4. Project 4 is the right one to select because it has a higher IRR and the duration is not being considered because time has already been considered

Keywords: justification, scrum, business

References:

Investopedia. (n.d.). Payback Rule. Retrieved from http://www.investopedia.com/walkthrough/corporate-finance/4/npv-irr/payback-rule.aspx

SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOK^TM Guide.), 3^rd Edition

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.

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/