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 Certification :How to Handle Request for Change or Change Requests in a Scrum Project?

Request for changes are usually submitted as Change Requests. Change Requests remain unapproved until they get formally approved. The Scrum Guidance Body usually defines a process for approving and managing changes throughout the organization. In the absence of a formal process, it is recommended that small changes that do not have significant impact on the project be directly approved by the Product Owner. The tolerance for such small changes could be defined at an organizational level or by the sponsor for a particular project. In most projects, 90% of Change Requests could be classified as small changes that should be approved by the Product Owner. So, the Product Owner plays a very important role in managing changes in a Scrum Project.

The following diagram summarizes the change approval process used in a Scrum project:

Changes that are beyond the tolerance level of the Product Owner may need approval from relevant stakeholders working with the Product Owner. At times, if a requested change could have a substantial impact on the project or organization, approval from senior management (e.g., Executive Sponsor, Portfolio Product Owner, Program Product Owner, or Chief Product Owner) may be required. 

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

Change Requests for the project are discussed and approved during the Develop Epic(s), Create Prioritized Product Backlog, and Groom Prioritized Product Backlog processes. Approved Change Requests are then prioritized along with other product requirements and their respective User Stories and then incorporated into the Prioritized Product Backlog.

The following diagram shows how the Prioritized Product Backlog is updated with Approved Changes

So, to conclude it can be said that Scrum development projects welcome change by using small development cycles that incorporate customer feedback on the project’s deliverables after each Sprint. This enables the customer to regularly interact with the Scrum Team members, view product increments as they are ready, and change requirements earlier on in the development cycle. Also, the portfolio or program management teams can respond to Change Requests pertaining to Scrum projects applicable at their level.

How is Business Justification Assessed and Confirmed in a Scrum Project?

Business justification is first assessed prior to a project being initiated and is continuously verified throughout the project lifecycle. The following steps capture how business justification is determined:

In the first step, 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 and involves considering the various factors specified in section 4.4.1. 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. Generally, this consists of executives and/or some form of a project or program management board.

Here is a video on business justification in Scrum projects: 

http://www.scrumstudy.com/watch.asp?vid=593

In the second step, as and when the decision makers approve the Project Vision Statement, it is baselined and considered as the business justification for the project. 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. This could happen in several Scrum processes including Conduct Daily Standup and Groom Prioritized Product Backlog. Throughout the project, the Product Owner should keep the business justification in the Project Vision Statement updated with relevant project information to enable the key decision makers to continue making informed decisions.

In the third step, 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. Benefits from Scrum projects are realized during Demonstrate and Validate Sprint, Retrospect Sprint, Ship Deliverables and Retrospect Project processes.

The following diagram summarizes the steps to determine business justification.

Business Justification and the Project Lifecycle

Scrum certification :10 reasons why SCRUMstudy is the best Scrum certification body!

Parameters	SCRUMstudy Scrum/Agile Certifications	Other Scrum Certifications
1. Based on Scrum Body of Knowledge (SBOK™ Guide)	All SCRUMstudy exams are based upon A Guide to the SCRUM Body of Knowledge (SBOK™ Guide – 340 pages) developed by SCRUMstudy. The SBOK™ is the definitive and detailed industry guide endorsed by Scrum experts. The propagation of Scrum is easier because all Scrum practitioners speak the same common language. SCRUMstudy offers this guide free on its website (http://www.scrumstudy.com/download-free-buy-SBOK.asp )	Other Scrum certifications are not based on any industry recognized publication. Most of the time the quality of the course is dependent only on the instructor and his or her experience.
2. Industry wide acceptance	The knowledge gained by getting a SCRUMstudy certification is universal in its application and has been applied by organizations in diverse projects spanning an eclectic mix of industries.	Other Scrum certifications are not accepted in all industries. Most of the time the learning from these certifications applies only to a small team in a industry.
3. Scalable Scrum	SCRUMstudy’s certifications are designed to enable delegates to scale Scrum to the Portfolio and Program levels and not just product design and project management. Each of the aspects of Product Development such as Business Justification, Quality, Cost, Risk, and Time are explained not just in the Project level but also on a Portfolio and Program level since this is the way organizations work.	Usually, other Scrum certification training companies teach Scrum that can be applied for a small team of 6-8 people developing a software product. There is just no mention of how to scale Scrum to the Portfolio or Program level.
4. Established name in Scrum/Agile certifications	SCRUMstudy's certification training is provided through its Authorized Training Partners (A.T.P) all across the globe. With more than 150 ATPs globally, SCRUMstudy has the widest network of accredited training companies offering its certifications. SCRUMstudy certifications are widely reputed and accepted by various Fortune 500 companies such as Apple, IBM, HP, Bank of America, AT&T, Dell, Verizon, Lockheed Martin, and Pepsico.	Other Scrum certification companies conduct their training through a much smaller network of trainers or training companies; and do not have the same level of credibility in the market that SCRUMstudy has.
5. Active Discussions to share and learn	SCRUMstudy engages the Scrum/Agile community through active discussions in LinkedIn, Twitter, Facebook, Google Plus, multiple Discussion Forums and Blogs. The SCRUMstudy LinkedIn Group is the most active Group for Scrum on LinkedIn (https://www.linkedin.com/groups/SCRUMstudy-1-Group-Scrum-Agile-6718717) .	Usually, other certification providers do not have such high activity discussion forums to engage their community.
6. Multiple free resources for Scrum & Agile Community	SCRUMstudy provides a wide range of free resources such as 5+ hours of high quality videos, useful case studies, interactive mobile apps, blogs, and articles, thereby contributing to the increased awareness of Scrum in the Scrum and Agile communities.	No other Scrum Certification provides high quality content and free resources to students in multiple formats. The main focus of such certification providers is to get students to their paid classes, rather than help students succeed with best practices.
7. Free “Scrum Fundamentals Certified” - SFC Course	Through its free Scrum Fundamentals Certified (SFC) Course, SCRUMstudy not only introduces Scrum concepts to professionals but also helps them get an introductory certification for free. This free certification includes approximately 10 hours of free online self-study through videos, case studies, and guides. The free SFC certification is a great way to introduce Scrum to all employees in your organization.	Other Scrum certifications usually do not provide any free resources or help for students to get a basic idea of the Scrum and Agile concepts. In most cases, professionals are required to pay upfront before even getting their first lesson on Scrum.
8. Credible and standard testing environment	With an emphasis on providing candidates with a reliable and credible testing environment, we conduct our certification exams using our live online proctoring system unlike other certifying bodies. This allows you to take your certification exams from the comfort of your home. All exams will be proctored live and videos of the exams will be recorded and reviewed by our assessment team.	Other Scrum certifications do not have a standardized examination. Most of them only require candidates to be present for a workshop and take a test, the result of which has no bearing on whether the candidate qualifies for the certification. These kinds of certifications never have the credibility which companies require to select candidates for key roles.
9. Teaching methodology	SCRUMstudy A.T.P. use a scientifically proven and highly interactive teaching methodology including role-plays, case studies, and simulations explaining the key Scrum concepts for their Agile and Scrum certification courses. To ensure an enriching learning experience for all our students, each trainer associated with a SCRUMstudy A.T.P.is required to be an accredited SCRUMstudy Certified Trainer (SCT™).	Other Scrum certification “workshops” are actually lectures. They are not engaging or interactive and most of the times involve delegates (sometimes more than 50 in a class) hearing an instructor for hours without any structured role plays or case studies.
10. Experienced SCRUMstudy trainers	Any person who is qualified as a SCRUMstudy Certified Trainer (SCT™) undergoes a rigorous assessment process and he or she has to exhibit proficiency in the concepts of Scrum and Agile. All trainers are required to successfully pass three SCRUMstudy certification exams before they can be eligible to teach. Moreover, all feedback from students about their respective trainers is reviewed and all SCRUMstudy trainers regularly participate in "Train-the-Trainer" sessions which help them understand the nuances of our certifications and further cement their understanding of the Scrum Framework and Agile Philosophy.	Usually, other Scrum Certifications do not have such strict requirements for trainer accreditation, and thus the quality of their instructors may not be very high.

 To know more, visit http://www.scrumstudy.com

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