Business Justification : What are the Factors that Affect the Business Justification of a Project?

Business justification demonstrates the reasons for undertaking a project. It answers the question “Why is this project needed?” Business justification drives all decision making related to a project. So, it is important to assess the viability and achievability of a project not only before committing to significant expenditures or investment at initial stages of the project but also to verify the business justification for continuance throughout the project’s lifecycle. A project should be terminated if it is found to be unviable; the decision should be escalated to the relevant stakeholders and to senior management. The business justification for a project must be assessed at the beginning of the project, at pre-defined intervals throughout the project, and at any time when major issues or risks that threaten the project viability arise. Business justification for a project is typically analyzed and confirmed by the Product Owner. It is documented and presented in the form of a project Business Case prior to Initiate phase.

Once documented, the Product Owner should create a Project Vision Statement and obtain approval of the Project Vision Statement from the key decision-makers in the organization. Once the decision makers approve the Project Vision Statement, it is then baselined and forms the business justification. The business justification is validated throughout project execution, typically at predefined intervals or milestones, such as during portfolio, program, and Prioritized Product Backlog Review Meetings and when major issues and risks that threaten project viability are identified. The Product Owner confirms the achievement of organizational benefits throughout the project, as well as upon completion of the User Stories in the Prioritized Product Backlog.

The factors that influence a project’s business justification are: project reasoning, business needs, project benefits, opportunity costs, major risks, project timescales and project costs.

Here is a video on a project’s business justification: http://www.scrumstudy.com/watch.asp?vid=593

Let us now look at each of these factors. Project reasoning includes all factors which necessitate the project, whether positive or negative, chosen or not. For example, inadequate capacity to meet existing and forecasted demand, decrease in customer satisfaction, low profit, legal requirement, etc. Business needs are those business outcomes that the project is expected to fulfill, as documented in the Project Vision Statement. For example, automation of processes, enhanced efficiency of staff, etc.

Project benefits include all measurable improvements in a product, service, or result which could be provided through successful completion of a project. For example, increase in revenue by 5%, reduction in operational costs by 10%, etc. Opportunity cost covers the next best business option or project that was discarded in favor of the current project.

Scrum : What is the Scrum Approach to Managing Quality in a Project?

Generally, in a Scrum environment, the Product Owner’s focus is on business requirements and objectives. The Product Owner, being the Voice of the Customer (VOC), is responsible for communicating the requirements prior to the designing of a product or service to the Scrum Team. He/she should agree the acceptance and done criteria with the team and use them to accept or reject the deliverables once they are developed by the Scrum Team. The Product Owner can benefit greatly from the guidance available from the Scrum Guidance Body (either through quality documents or standards, or from quality experts). These specialists should work with the Product Owner and the customer to ensure the appropriate level of detail and information in the User Stories, since User Stories are the basis for the success of any Scrum project.

 Quality management in Scrum enables customers to become aware of any problems in the project early and helps them recognize if a project is going to work for them or not. In Scrum, quality is about customer satisfaction and a working product, not necessarily meeting arbitrary metrics. This distinction becomes very important from the customer’s point of view because they are the ones investing time and money in the project.

Here is a video on quality management in Scrum: http://www.scrumstudy.com/watch.asp?vid=585

Quality management in Scrum is facilitated through three interrelated activities:

·         Quality planning

·         Quality control

·         Quality assurance

A key benefit of quality planning is the reduction of technical debt. Technical debt—also referred to as design debt or code debt—refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project’s product. Technical debt accrues and must be paid in the future. To maintain a minimal amount of technical debt, it is important to define the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. Defining Acceptance Criteria is an important part of quality planning and it allows for effective quality control to be carried out during the project.

Quality control refers to the execution of the planned quality activities by the Scrum Team in the process of creating deliverables that are potentially shippable. It also includes learning from each set of completed activities in order to achieve continuous improvement. Within the cross-functional team, it is important to have the skills necessary to perform quality control activities. During the Sprint Retrospect Meeting, team members discuss lessons learned. These lessons act as inputs into continuous improvement and contribute to the improvement of ongoing quality control.

Quality is required not only in products, but also in processes. Quality assurance refers to the evaluation of processes and standards that govern quality management in a project to ensure that they continue to be relevant. Quality assurance activities are carried out as part of the work. In fact, quality assurance is a significant factor of the definition of Done. The deliverable isn't complete if appropriate quality assurance has not been conducted. Often, quality assurance is demonstrated during the Sprint Review Meeting.

Product Owners for respective projects, programs, and portfolios can monitor and evaluate quality assurance activities to ensure each team continues to agree and comply with the quality standards that have been set. End-to-end quality assurance may be addressed during final testing of the product, a Release, or a Sprint. A comparison of the number of issues encountered versus the number of User Stories completed can be done. The product components that have defects can be incorporated as Prioritized Product Backlog Items (PBIs), which can be worked upon by either the team or by one person at certain times during the Sprint, depending on the number of defects.

At times, the Scrum Guidance Body can define the processes and documents that can be referred to by Scrum Teams when doing their projects to ensure that uniform quality norms are followed by all projects within the company.

Scrum Master :How are Risks Assessed in a Scrum Project?

Risk management consists of five steps: identification, assessment, prioritization, mitigation, and communication. Risk identification is done throughout the life of a project. Once risks are identified, each risk is assessed with the objective of understanding its potential impact, how likely it is to occur, and when it could materialize. The overall effect on business value should also be estimated; if that impact is significant enough to outweigh the business justification, a decision must be made whether to continue the project.

To estimate the probability of a risks, various techniques may be used, including Probability Trees, Pareto Analysis, and a Probability and Impact Matrix. In addition to probability, risk assessment also evaluates the potential net effect of risks on the project or organization. These effects can be estimated using techniques such as Risk Models and Expected Monetary Value.

Here is a video on risk assessment: http://www.scrumstudy.com/watch.asp?vid=604

Some of the recommended techniques that can be used to assess risks are risk meetings, probability trees, Pareto analysis, probability impact grid, and expected monetary value. Let us look at them using examples.

Risk meeting: risks could be easily prioritized by the Product Owner by calling a meeting of the Scrum Core Team and optionally inviting relevant Stakeholders to the meeting. The team could meet and prioritize different risks based on their subjective assessment of the impact of the risks on project objectives.

Probability trees: Potential events are represented in a tree with a branch extended for each possible outcome of a risk event. The probability of each possible outcome is indicated on the appropriate branch and then multiplied by its assessed impact to get an expected value for each outcome possibility. The outcome values are then summed together to calculate the overall expected impact of a risk to a project (see Figure).

Pareto analysis: This technique of assessing risk involves ranking risks by magnitude which helps the Scrum Team address the risks in the order of their potential impact on the project. For example, in Figure 7-2, Risk 1 has the highest impact and should preferably be addressed first.

Probability impact grid: Each risk is assessed for its probability of occurrence and for its potential impact on project objectives. Generally, a numerical rating is assigned for both probability and impact independently. The two values are then multiplied to derive a risk severity score (or PI value), which can be used to prioritize risks.

For example, the risk severity score for a risk with a Probability of 50% and an Impact rating of .6 would be calculated as follows:

0.5(Probability) x 0.6(Impact) = 0.3

The rating schemes used are determined within the organization or for the project. Often a decimal scale is used, from zero to one, where a 0.5 probability rating would indicate 50% likelihood. Other options include a scale of one to ten, or High (3), Medium (2), and Low (1). The following diagram depicts the use of the decimal scale. Each risk is rated on its probability of occurrence and impact on an objective scale.

The method of assigning probability and impact values to risks varies depending on the project and number of risks being evaluated, as well as existing organizational processes and procedures. However, by applying the simple P x I formula, risk severity can be calculated on a numerical or categorical scale.

Expected monetary value: The monetary value of the risk is based on its Expected Monetary Value (EMV). EMV is calculated by multiplying the monetary impact by the risk’s probability, as approximated by the customer.

Expected Monetary Value = Risk impact (in dollars) x Risk probability (as percentage)

For example, a risk with an estimated negative impact of $1,000 and a 50% probability of occurring would result in an EMV as follows:

EMV = $1,000 x 0.50 = $500

Scrum Projects :How is Technical Debt Handled in Scrum Projects?

One of the guiding principles of Scrum is to develop the functionality of the highest priority to the customer first. Less important features are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. This approach gives the Scrum Team the required time to focus on the quality of essential functionality. A key benefit of quality planning is the reduction of technical debt. Technical debt—also referred to as design debt or code debt—refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project’s product. Technical debt accrues and must be paid in the future.

Some causes of technical debt can include the following:

·   Quick-fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals, etc.

·         Inadequate or incomplete testing

·         Improper or incomplete documentation

·         Lack of coordination among different team members, or if different Scrum Teams start working in isolation, with less focus on final integration of components required to make a project or program successful

·         Poor sharing of business knowledge and process knowledge among the stakeholders and project teams

·   Too much focus on short-term project goals instead of the long-term objectives of the company. This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs.

In Scrum projects, any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The functionality must satisfy these criteria to be considered Done. As the Prioritized Product Backlog is groomed and User Stories are prioritized, the team creates Working Deliverables regularly, preventing the accumulation of significant technical debt. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.

Here is a video on managing Technical Debt in Scrum projects: http://www.scrumstudy.com/watch.asp?vid=585

To maintain a minimal amount of technical debt, it is important to define the product required from a Sprint and the project along with the Acceptance Criteria, any development methods to be followed, and the key responsibilities of Scrum Team members in regards to quality. Defining Acceptance Criteria is an important part of quality planning and it allows for effective quality control to be carried out during the project.

Technical debt is a very big challenge with some traditional project management techniques where development, testing, documentation, etc. are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release. Also, the cost of changes is very high in such circumstances as problems surface in later stages of the project. Scrum framework prevents the issues related to technical debt by ensuring that Done deliverables with Acceptance Criteria are defined as part of the Sprint Backlog and key tasks including development, testing, and documentation are done as part of the same Sprint and by the same Scrum Team.

Scrum : Done Criteria :What are the Key Differences between Done Criteria and Acceptance Criteria?

Acceptance Criteria are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought. Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project.

The diagram illustrates the concept of Acceptance Criteria along with product increment flow:

The major difference between “Done Criteria” and “Acceptance Criteria” is that while Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

·         Reviewed by other team members

·         Completed unit testing of the User Story

·         Completion of quality assurance tests

·         Completion of all documentation related to the User Story

·         All issues are fixed

·         Successful demonstration to stakeholders and/or business representatives

As with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done. The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms. The definition of Done is typically determined and documented by the Scrum Guidance Body.

The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases. The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

To conclude, you can watch the following video on Acceptance Criteria: http://www.scrumstudy.com/watch.asp?vid=594

Scrum :Time boxing :How Relevant is Time-boxing in Scrum?

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

·         Efficient development process

·         Less overheads

·         High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating). Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

Here is a video on time-boxing in Scrum: http://www.scrumstudy.com/watch.asp?vid=450

The following are some of the time-boxed meeting carried out as part of a Scrum project:

·         Sprint—A Sprint is a Time-boxed iteration of one to six weeks in duration during which the Scrum Master guides, facilitates, and shields the Scrum Team from both internal and external impediments during the Create Deliverables process. This aids in avoiding vision creep that could affect the Sprint goal. During this time, the team works to convert the requirements in the Prioritized Product Backlog into shippable product functionalities. To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-boxed to 4 weeks, unless there are projects with very stable requirements, where Sprints can extend up to 6 weeks.

·         Daily Standup Meeting—The Daily Standup Meeting is a short daily meeting, Time-boxed to 15 minutes. The team members get together to report the progress of the project by answering the following three questions:

1.     What did I complete yesterday?

2.     What will I complete today?

3.     What impediments or obstacles (if any) am I currently facing?

·         Sprint Planning Meeting—This meeting is conducted prior to the Sprint as part of the Create Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint.

·         Sprint Review Meeting—The Sprint Review Meeting is Time-boxed to four hours for a one-month Sprint. During the Sprint Review Meeting that is conducted in the Demonstrate and Validate Sprint process, the Scrum Team presents the deliverables of the current Sprint to the Product Owner. The Product Owner reviews the product (or product increment) against the agreed Acceptance Criteria and either accepts or rejects the completed User Stories.

·         Retrospect Sprint Meeting—The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-month Sprint and conducted as part of the Retrospect Sprint process. During this meeting, the Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes followed, tools employed, collaboration and communication mechanisms, and other aspects relevant to the project. The team discusses what went well during the previous Sprint and what did not go well, the goal being to learn and make improvements in the Sprints to follow. Some improvement opportunities or best practices from this meeting could also be updated as part of the Scrum Guidance Body documents.

The following diagram summarizes the Time-boxed durations for Scrum-related meetings:

Scrum Projects :How are Risks Managed in Scrum Projects

Risk is defined as an uncertain event that can affect the objectives of a project and may contribute to its success or failure. Risks with a potential for positive impact on the project are called opportunities, whereas threats are risks that could negatively impact a project. Managing risk must be done proactively, and it is an iterative process that should begin at project inception and continue throughout the life of the project. The process of managing risk should follow some standardized steps to ensure that risks are identified, evaluated, and a proper course of action is determined and acted upon accordingly.  

Risk Management consists of five steps:

·         Risk identification: Using various techniques to identify all potential risks.

·         Risk assessment: Evaluating and estimating the identified risks.

·         Risk prioritization: Prioritizing risk to be included in the Prioritized Product Backlog.

·         Risk mitigation: Developing an appropriate strategy to deal with the risk.

·         Risk communication: Communicating the findings from the first four steps to the appropriate stakeholders and determining their perception regarding the uncertain events.

Here is a video on risk management in Scrum: http://www.scrumstudy.com/watch.asp?vid=604

Risk identification involves the Scrum Team members who attempt to identify all risks that could potentially impact the project. Only by looking at the project from different perspectives, using a variety of techniques, can they do this job thoroughly. Risk Identification is done throughout the project and Identified Risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Groom Prioritized Product Backlog, and Demonstrate and Validate Sprint.

Risk assessment helps in understanding the potential impact of a risk, how likely it is to occur, and when the risk could materialize. The overall effect on business value should be estimated; if that impact is significant enough to outweigh the business justification, a decision must be made whether to continue the project. The assessment of risks is done with regard to probability, proximity, and impact. Probability of risks refers to the likelihood of the risks occurring, whereas proximity refers to when the risk might occur. Impact refers to the probable effect of the risks on the project or the organization. To estimate the probability of a risks, various techniques may be used, including Probability Trees, Pareto Analysis, and a Probability and Impact Matrix.  In addition to probability, risk assessment also evaluates the potential net effect of risks on the project or organization. These effects can be estimated using techniques such as Risk Models and Expected Monetary Value.

Under the risk prioritization step, Identified Risks are captured in a Prioritized Product Backlog—so a Prioritized Product Backlog could also be referred to as a Risk Adjusted Prioritized Product Backlog. The prioritized User Stories from the existing Prioritized Product Backlog and the prioritized list of risks are then combined to create an updated Prioritized Product Backlog which includes the Identified Risks.  The following diagram illustrates the risk prioritization process:

Risk mitigation can be proactive or reactive. In the case of a risk, a plan B may be formulated, which can be used as a fall-back in case the risk materializes—such a plan B is a reactive response. Sometimes risks are accepted and are an example of a risk response which is neither proactive nor reactive. Risks are accepted because of various reasons, as in a situation where the probability or impact of the risk is too low for a response. Acceptance can also be the case in a situation where the apprehension of secondary risks may deter the product owner from taking any action. The effort made by the Product Owner to reduce the probability or impact—or both—of the risk is an example of a proactive response to mitigating risks.

Risk communication is important because stakeholders have an interest in the project and need to know the hindrances that the project may face. Information provided to stakeholders related to risk should include potential impact and the plans for responding to each risk. This communication is on-going and should occur in parallel with the four sequential steps discussed thus far—risk identification, assessment, prioritization and mitigation. The Scrum Team may also discuss specific risks related to their Tasks with the Scrum Master during Daily Standup Meetings. The Product Owner is responsible for the prioritization of risks and for communicating the prioritized list to the Scrum Team.

Other Resources:

1. http://www.scrumstudy.com/certification.asp

2. http://www.scrumstudy.com/free-resources.asp

3. http://www.scrumstudy.com/scrum-in-six-minutes.asp