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:
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:
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:
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
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:
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:
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.
Keywords: justification, scrum, business
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 (SBOKTM Guide.), 3rd Edition
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/
Scrum is a popular agile method based on its flexibility, adaptability, and effectiveness in delivering value quickly and continuously on a project. The Scrum framework excels in comparison to traditional project management methods in the way risks are intrinsically minimized throughout the entire lifecycle. All projects are impacted by some form of risk, whether it be negative (threats) or positive (opportunities). The goal is to maximize the impact and probability of positive risks and to reduce or eliminate negative risks. This article focuses mainly on negative risks. Most projects begin with high levels of risk because of a large number of uncertainties. The Scrum framework has built-in benefits that help to keep the impact of risks at very low levels. Scrum practices inherently mitigate risk based on the following characteristics of the framework:
Figure 1: Risk Register (Agile Michael, 2016)
Key Words: Scrum, Agile, Risks
SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition
Michael, Agile (2016). Risk Burndown Charts. Retrieved from https://agilemichaeldougherty.wordpress.com/2016/02/04/risk-burn-down-chart/
Agile Planning involves quantifying the pace that a team can develop user stories into working software. The team’s velocity is the measurement of its throughput which is used to establish expectations regarding future delivery dates. To establish delivery dates, we examine the total amount of work for the project and divide it by the established team velocity. We then gauge how many iterations are needed to deliver the entire project. For example, if we have 100 story points to complete the project and the team’s velocity is estimated at 15 points per iteration, we calculate the number of iterations needed as follows:
As the team begins the Sprints, there are two things that can occur.
Release Planning involves a commitment to plan the delivery of a product increment of value. The Scrum team is responsible for planning the releases. Table 1 describes the responsibility of the team during this ceremony.
Table 1. Release Planning Roles and Responsibilities
What Happens Before the Release Meeting?
Prior to the start of the Release Planning meeting, the Product Owner needs to ensure that the Product Backlog has been prioritized. The Scrum Team should provide input about capabilities, velocity and any technical impacts. The vision statement, market and business objectives should be established. The Product Owner, if applicable, needs to announce whether new product backlog items will be needed.
Release Planning Data and Output
In terms of needed data for the Release Planning meeting, data from previous Sprints and releases would be beneficial. Stakeholders typically, but not always, provide feedback about the product, market conditions and proposed deadlines. Also useful are Action Plans and goals from previous releases and retrospectives. There may be additional items and unresolved defects that should be revisited. The team should be on hand to discuss the relevant development and architectural information. In addition, the team’s estimated velocity based on previous iterations should be considered as well as input from other technical team and subject matter experts to properly manage dependencies. The output from Release Planning includes but is not limited to the following:
The Sprint Planning
Every Sprint starts with a Sprint Planning meeting. All team members should be present because this is the chance to determine how much work can be completed in the upcoming Sprint. The Guide to the Scrum Body of Knowledge (SBOK Guide) suggests that a one-month Sprint Planning Meeting has two parts and is time-boxed to eight hours:
The User Stories are estimated, approved and committed. Each Scrum Team members participate in an estimation of the tasks using common techniques such as Planning Poker. In the case of where the estimating is lengthy, it would mean that the team was not totally prepared to start the Sprint. Effort Estimation is used to select the tasks that are needed to complete the work. The Sprint Backlog is created as well as the establishment of the Burndown Chart and the team commitment is made verbally.
There are two events that should not occur during a Sprint Planning meeting:
According to the rules of Scrum, the length of an iteration should not be longer than four weeks. The length of the Sprint is the determining reason as to how fast the Scrum team can inspect and adapt to fluctuating situations and continuing to learn. By having a maximum length for the Sprint, the Scrum Team is practically guaranteed a minimum benefit. If a Sprint is longer than four weeks, the benefits of Scrum are lessened. Risks have the potential to be increased because of short-term planning, adapting to change, the development of the team, detection of errors and the timing of business opportunities.
Task Estimates to Story Points
Story Points represent a high-level estimation of complexity that is used prior to Sprint Planning. Story Points and velocity are relative measures that provide agreed upon guidelines about the user stories that will be committed in the iterations. On the other hand, task estimates based on hours are very low-level estimates that are used to represent the specific effort in hours that will be required to complete the User Stories during a Sprint. Tasks estimates should be as accurate as possible whereas Story Points are never expected to be exact. Since story points and task hours are used for very different purposes for different situations, the attempt to make a correlation between the two is not recommended. Figure 1 outlines when to use Story Points and Task Hours.
Figure 1. Story Points and Task Hours
Agile Advice by Berteig. (2013). The Rules of Scrum: Every Sprint is Four Weeks or Less in Duration. Retrieved from http://www.agileadvice.com/2013/05/16/scrumxplean/the-rules-of-scrum-every-sprint-is-four-weeks-or-less-in-duration/
Agile in a Nutshell. (2016). (n.d.). Planning. The Fine Art of Expectation Setting. Retrieved from http://www.agilenutshell.com/planning
CA Technologies. (2017). Release Planning. Retrieved from https://help.rallydev.com/release-planning
Scrum Alliance. (2012). Story Points Versus Task Hours. Retrieved from https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours
SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition
SCRUMstudy. (2017). What Happens at a Sprint Planning Meeting? Retrieved from https://www.scrumstudy.com/blog/what-happens-at-a-sprint-planning-meeting/