Agile Thoughts

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

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

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:

• Total Effort/Estimated Team Velocity = Number of Iterations
• 100/15 = 6.66 = 7 iterations

As the team begins the Sprints, there are two things that can occur.

1. The team will deliver faster than projected
2. The team will deliver slower than expected

Release Planning

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:

• Release Plan
• Team Commitment to the Plan
• Suggestions for improvement regarding future Release Planning meetings
• New user stories for the Release Backlog

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:

1. Objective Definition – This event occurs during the first half of the meeting where the Product Owner discusses the highest priority User Stories in the Prioritized Product Backlog to the team. The Scrum Team then defines the Sprint Goal.
2. Task Estimation – This event occurs during the second half of the meeting where the Scrum Team determines how to finish the work in the Sprint Backlog to meeting the Sprint Goal.

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:

1. Grooming – The refinement of the User Stories that should be done prior to the Sprint Planning Meeting.
2. Updates or Revisions – The User Stories should be clearly defined and ready to be broken down into tasks and then estimated. Updates to the User Stories should not occur during Sprint Planning.

Iterations Length

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

References:

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

SCRUMstudy. (2017). What Happens at a Sprint Planning Meeting? Retrieved from https://www.scrumstudy.com/blog/what-happens-at-a-sprint-planning-meeting/