Scrum Master Certification + 2 Mock Test (98% Passing Rate)

Scrum framework allows you to implement Agile development methodology. Unlike the waterfall software development life cycle, the distinctive feature of Scrum is the iterative process of developing.

Development divides into several phases. Each of them results in a ready-to-use product. At the end of each step (called sprint in Scrum terminology), a ready product is delivered to a customer. Customer’s feedback helps reveal possible problems or change the initial plan if needed. If you want your project to strictly follow the main principles of Agile manifesto, you can use Scrum and be sure that you’re on the right path.

The first step is where Product Owner captures all the feature request in a product backlog from stakeholders.  This happens in various workshops and stakeholders meeting. Once those features has been captured. Product wonder concentrate on drafting user stories which represent functional or non functional part of the feature. After that Product owner has to prioritise the backlog according the value each user story possess.

Then it comes to the Sprint Planning and Sprint Backlog Creation:  Scrum team selects the most important user stories from the product backlog. Then team members should decide how they will solve this. The Sprint backlog should be created next. It consists of user stories that will be completed during the current sprint. The amount of these stories depends on their duration in story points assigned to each story during the evaluation stage. The team should be capable of finishing all these stories on time.

After actual user stories for the current phase are chosen, the sprint begins.

To track the current working process, a task board is commonly used. There are usually big cards with the names of particular user stories and a bundle of little sticky notes with a description of single tasks which are needed for implementation of this or that story.

These cards are arranged according to their importance. When work on a task has been started, the corresponding sticker is moved from the “To do” field to the “In progress” one. When work is completed, the sticker can be moved to the “Testing” field, and after the task is successfully tested, the sticker goes to the “Done” field.

The result of every sprint is a product demonstration. The Scrum team creates a review and demonstrates the results of their work. On this basis, the stakeholders take a decision about further project changes.

Then comes Retrospective,

Retrospective’s main aim is to discuss the results and determine the ways how to improve the development process on the next step. The team should conclude what went well during the working process and what can be done better during future iteration. When the ways of improvement are defined, the team can concentrate on the next sprint planning.

The main distinctive features of Scrum are agility and continuous progress. It’s provided mostly by permanent communication and close cooperation between the stakeholders at each step. At the phase of sprint planning, the product owner communicates with the scrum team. They define how they can divide the existing user stories into several tasks.

During the regular scrum meetings, the team members discuss the implementation of each particular task and the ways of solving possible problems. When the sprint is finished, the customer can evaluate the working product functionality at the current iteration. There is a possibility for him to arrive at a decision about further improvements or change the initial project’s paradigm. Finally, all information received during these steps can be used to improve the next sprint results, which helps optimize the development process in the best possible way.

So this was the early win video for you which actually describes all necessary steps for a single iteration in Scrum Framework.

Scrum is a framework not a methodology. Because a methodology gives you lots of prescription. First you do this and you do this and then you do this. And follow all this things. And ooh you better not change anything unless everybody in the organisation agrees and so on.

It is not the idea behind scrum. Scrum is empirical.

Meaning we learn and then we adapt. And we organise as a team and we do the right things. Be proficient in what's going to make our team successful.

All teams are different. Some teams are more energetic, some are quality focused. That said if we all follow the same process then in general we wont be successful. Its light weight and focusses delivering value in increments. Generally in 1 to 4 weeks.

There are three factors that are really really critical in my opinion for scrum.

1. Transparency

2. Adaption

3. Inspection

What we do must be transparent to the team and to our stakeholders. Because if we don’t get that feedback and we don’t do what we are suppose to be doing. How we make sure that we are doing the right thing. If we are not constantly inspecting and adapting, looking at how we work in what we are doing. And making changes to improve. How are we get any better.

Scrum theory is based on the experiential learning circle. This states that knowledge and understanding come from a process of planning something, doing it, reviewing how it worked and then adapting the process to be used the next time.

Scrum employs an iterative, incremental approach to optimize predictability and control risk. 

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Transparency: Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

For example

A common language referring to the process must be shared by all participants; and, • Those performing the work and those inspecting the resulting increment must share a common definition of “Done”.

Inspection: Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

Adaptation: If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of this document:

Sprint Planning

Daily Scrum 

Sprint Review

Sprint Retrospective

This PDCA cycle you see on the screen is advocated by Deming finds an important place in continual improvement. It helps a process to improve its performance on a staged and steady manner. This diagram is a very popular among Quality professionals and management text books.

The Scrum guide doesn’t provide much of a definition or explanation of these values. It says it is up to the team to “learn and explore those values”. Which is in the Scrum spirit of providing a minimal framework within which a team can learn and grown and find their own ways.

Commitment – People personally commit to achieving the goals of the Scrum Team

Courage – The Scrum Team members have the courage to do the right thing and work on tough problems

Focus – Everyone focuses on the work of the Sprint and the goals of the Scrum Team

Openness – The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work

Respect – Scrum Team members respect each other to be capable, independent people.

Value Misunderstanding

Getting the value right

Commitment

Committing to something that you don’t understand because you are told to by your boss. Committing yourself to the team and Sprint Goal.

Focus

Focusing on keeping the customer happy. Being focused on the Sprint and its goal.

Openness

Telling everyone everything about all your work. Highlighting when you have challenges and problems that are stopping you from success.

Respect

Thinking you are helping the team by being a hero. Helping people to learn the things that you are good at and not judging the things that others aren’t good at.

Courage

Even after the decision has been made continuing to push back. Being transparent, but willing to change even if that means accepting that you are wrong, or that your opinion is not the direction that the team is going.

The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.

1. Individuals and Interactions Over Processes and Tools

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

2. Working Software Over Comprehensive Documentation

Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation

Negotiation is the period when the customer and the product manager work out the details of a delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.

4. Responding to Change Over Following a Plan

Do you have a change management process in place in the organization? Does this process address to how the priorities change over in case a change request is raised? The change request automatically takes a priority over the plan in adherence. The reason behind this is the change itself. If there is a request for a change, it means there is some shortfall in the current process. This shortfall that was not until yesterday might have arisen due to change in policies, strategies or any processes.

On agile projects, the ability to not only respond to but welcome change is the most powerful tool. The ability to embrace change is built in to every agile process, practice and attitude. For example, while scrum has a rule of "no change within the sprint", you are free to add, remove, reprioritize or even chuck away the whole product backlog. In essence, this means that scrum accommodates any degree of change in between sprints. This also means that the shorter your sprints are, the more opportunities you have to accommodate change! Many agile teams now only have a sprint cycle of 1 week or shorter.

Another example of how change is inherently built into agile is its feedback cycle. Besides sprint cycles, agile encourages teams to find other feedback cycles and to shorten them as much as possible.

1. Customer satisfaction through early and continuous delivery of useful software

Customer satisfaction is obtained through early delivery of products to customer for testing and feedback, through continuous delivery to let customer know the progress and through delivery of values to the customers by fulfilling the top priority requirements first. The output of each iteration is working code that can be used to evaluate and respond to changing and evolving user requirements.

2. Welcome changing requirements, even late in development

This places emphasis on responsiveness to change as opposed to tight alignment to approved plans. The change control process is simplified and no formal documentation and approval required. This is harness change for the customer’s competitive advantage because it allow fast response to latest changes in external environment to enhance competitive advantage to emerging opportunities.

3. Frequently Delivered Software(weeks rather than months)

This provides immediate values to the customers by delivering working features. Each iteration or Sprint should lead to a release of a product. The teams make sure that each feature is fully developed, tested, styled, and accepted by the product owner before counting it as delivered. The project team activities can be better structured with the fixed delivery timeframe to focus on delivery of value.

4. Close, daily cooperation between business people and developers

Agile development principles include keeping requirements and documentation lightweight, and acknowledging that change is a normal and acceptable reality in software development. This makes close collaboration particularly important to clarify requirements just-in-time and to keep all team members ‘on the same page’ throughout the development.

5. Projects are built around motivated individuals, who should be trusted

Projects are built around motivated individuals who are given the environment and support they need, and trusted to get the job done. Team members choose the jobs they are most interested in through self-organization and not through external management influence. Micromanagement and top-down approach to management are shunned.

6. Face-to-face conversation is the best form of communication

Obtain direct feedback by going to the source of problem or confusion and use oral communication at the workplace for the benefit of osmotic communication. Virtual team conversations are facilitated via video conferencing.

7. Collocation and pair programming

This principle is practiced via colocation and pair programming. Collocation involves collocating a number of teams in the same open area and pair programming, which entails two programmers sharing a single workstation (one screen, keyboard and mouse). The programmer at the keyboard is usually called the "driver", the other, also actively involved in the programming task but focusing more on overall direction is the "navigator"; it is expected that the programmers swap roles every few minutes or so. 

This leads to increase in code quality because "programming out loud" leads to clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys. It also yields better diffusion of knowledge among the team. Other benefits include better transfer of skills, large reduction in coordination efforts, and improved resiliency of a pair to interruptions.

8. Sustainable development, able to maintain a constant pace

Agile methodologies seek work-life balance among the team members and promote happiness by avoiding burnout or exhaustion. Through close collaboration and by being alert and creative, these methodologies avoid long nights and weekends, during which people try to undo the errors of unresponsive planning. The sponsors, developers, and users are able to maintain a constant pace indefinitely.

9. Excellence through Reflection

The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. These retrospective meetings ensure that the lessons learned during the project are put back into the next iteration.

10. Simplicity—the art of maximizing the amount of work not done—is essential

The Pareto principle or the 80/20 rule is applied. It means that typically 80% of your results may actually come from only 20% of your efforts!  The idea is to focus on the important 20% of effort that gets the majority of the results. If you have control over the scope, and if speed-to-market is of primary importance, why not seek to deliver the important 80% of your product in just 20% of the time?

Focus on what are essential to create value to the project and customer not on distractors that do not add values like components, process, etc.

11. Self-organizing teams

The team is utterly self-managing under the Scrum methodology. It has autonomy and responsibility to meet the goals of the sprint and is responsible for determining how it will accomplish the work to be completed. The basic principle is that the team knows best how to carry out the work, not the project manager or human resources department.

12. Regular adaptation to changing circumstance

This is in contrast to capturing all known requirements and baseline the scope so that any other changes are subject to change control. Agile Development holds that that requirements emerge and evolve, and that however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. And in the time you would have spent analyzing and reviewing requirements and designing a solution, external conditions could also have changed.

Here are some tips on taking (and passing) the Scrum.org Professional Scrum Master I (PSM I) assessment and gaining certification:

Read the Scrum Guide and get really familiar with it. This is the primary source of all answers for the assessment

Review the Scrum glossary for quick definitions of key terms

Ensure you understand Burndown Charts. Although not a mandatory part of Scrum, there are a few questions on them in the assessment pool. They are a tool for the Development Team to track work remaining. Commonly this is at Sprint level but could be for a release or the whole Product.

Do the Scrum Open assessment until you can do it fast and score close to 100% 3 times in a row. You do not need to do the Developer Open, the Product Owner Open or the Nexus Open as these are intended for preparation for other assessments,

Take my practice test at the end of this course

When you are ready to take the assessment for real:

Go to Scrum.org. Select PSM 1 certification. Register with Fee $150

Use the link in the email you will have received from Scrum.org

Have the Scrum guide and the Scrum glossary to hand and use it to look up what you need

Don’t spend too long on each question. If unsure of an answer, note down the question number and move on. Completing all the questions in the time box can be challenging.

Come back to the hard questions at the end and use your time to think them over.

Google the question if really unsure, but be careful as this takes time and there are lots of unreliable sources out there.

If time permits, check all your answers before the end.

Remember the Scrum Master is a coach and servant leader. He/she does not tell the team what to do or how to do it, except in matters relating to the Scrum framework.

Scrum Roles - The Scrum Team

Within the Scrum Framework three roles are defined:

The Development Team

Scrum Master

Scrum Product Owner

Each of these roles has a defined set of responsibilities and only if they fulfill these responsibilities, closely interact and work together they can finish a project successfully.

The Product Owner is responsible for maximizing return on investment (ROI) by identifying product features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list. The Product Owner has profit and loss responsibility for the product, assuming it is a commercial product. Product Owner in Agile is like a spokesperson for customer needs. Lets have a look at the major responsibilities of a Product Owner:

A Product Owner owns the Product backlog and writes user stories and acceptance criteria. Although he can seek help from the development team as well as SME’s.

A Product Owner is responsible for prioritizing the Product Backlog. He is responsible for deciding the release date and the content to be integrated.

A Product Owner accepts or rejects product backlog item.

A Product Owner has the power to cancel the Sprint, if he thinks the Sprint goal is redundant.

A Product Owner is the one who is responsible for the Return on Investment (ROI) of the product.

Scrum Master: Roles and Responsibilities

The Scrum Master helps the scrum team learn and apply Scrum to achieve business value. The Scrum Master does whatever is in his power to help the Team, Product Owner and organization to be successful. The Scrum Master is not a project manager, nor the team lead, or team representative. Instead, the Scrum Master serves the Team; he or she helps to remove impediments, protects the Team from outside interference, and helps the Team to adopt Agile development practices. He educates, coaches and guides the Product Owner, Team and the rest of the organization.

Scrum Master ensures everyone follows the practices prescribed by Scrum.

A Scrum Master is a facilitator and Servant Leader who encourages and demands self-organization from the development team.

A Scrum Master enables close cooperation across all roles and functions, addresses resource issue and disobedience of scrum practices.

A Scrum Master protects the team from external and internal distractions.

A Scrum Master removes impediments so the team can focus on the work at hand and follow scrum practices.

A Scrum Master is not typically a manager or lead, but he is an influential leader and coach who does not do direct command and control.

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

A Development Team is a collection of individuals working together to develop and deliver the requested and committed product increments. It comprises of cross-functional members who are capable of achieving the sprint goals. This could include software engineers, architects, programmers, analysts, system admins, QA experts, testers, UI designers, etc.

The Development Team builds the product that the Product Owner indicates: the application or website

The Development Team includes all the expertise necessary to deliver the potentially shippable product each Sprint

The Development Team is self-organizing, with a very high degree of autonomy and accountability.

The Development Team decides how many items to build in a Sprint, and how best to accomplish that goal.

The Development Team is a cross functional, small and self-organizing team which owns the collective responsibility of developing, testing and releasing the Product increment.

They have to update the status and the remaining efforts for their tasks to enable creation of a Sprint Burndown.

They have to perform the short Daily Sprint Meeting.

Characteristics of a Scrum TeamTeam members share the same norms and rules

The Scrum team as a whole is accountable for the delivery

The Scrum Team is empowered

It is working as autonomous as it is possible

The Scrum Team is self organizing

The skills within the Scrum team are balanced

A Scrum Team is small and has no sub-teams

The people within the Scrum Team work full time in the team

People are collocated

Rules & NormsOf course their environment defines some of the norms the teams have to follow, but some rules and norms are developed during the Norming phase. This set of common rules is quite important. Otherwise the team members would have to constantly waste valuable time to switch between different value systems and rule sets. Examples for such norms and rules are: time and location of the Daily Scrum Meeting

the Definition Of Done (DoD) used to decide if work is finished or not

coding guidelines

tools to use

AccountabilityThe Scrum Team as a whole is responsible to deliver the committed delivery in time and with the defined quality. A good result or a failure is never attributed to a single team member but always the result of the Scrum Team.Empowerment & Self organizationThe Scrum Team has to be empowered to define what it will commit to deliver at the end of the sprint

how the expected results have to be broken down into tasks

who will perform the task and in which order they are performed

Only if the Scrum Team is empowered to decide these things it will work with the highest possible motivation and performance.Balanced set of skillIndividuals within the Scrum Team will most certainly have specialized skills and focus. However to achieve best possible performance it would be optimal to have a balanced set of skills. Only then the Scrum Team will be able to deal with the ever-changing challenges and can act as autonomous as it is possible.On one hand this means that a Scrum Team should be multidisciplinary (developers, tester, architects etc) right from the beginning. On the other hand this also means that each team member should learn a little bit of each other's specialization, e.g. a if required to finally reach the committed goal a developer should also perform or write tests.As a consequence this also means that within the Scrum Framework it is not differentiated between e.g. "tester" and "architect", they all share the same title "Scrum Team Member" even if the primary skill is not to develop production code.Size of the Scrum TeamScrum Teams are small. The ideal size is 7 +/- 2 people.If there are more people the communication overhead gets too large and the team should be split into multiple Scrum Teams. These Scrum Teams should be coordinated and communicate with each other but otherwise work independently.

Perhaps THE most important element to Scrum and Agile is the enthusiasm for communication, openness and transparency.

These factors underpin everything we do in our daily work using Agile and Scrum practices; they are the whys we value customer collaboration over contract negotiations and why we’re not afraid to respond to change as we know that feedback is important.

Agile approaches only asks that we learn from our mistakes and/or identify new ways to improve. As one of the principles of the Agile Manifesto states:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

It is with this call for open communication that Scrum encourages us to hold five key events during a Sprint, all intended to help us work efficiently and closely together, as well as to improve our knowledge and become more effective in the future.

These five events are:

1. Sprint Planning

2. Daily Scrum

3. Sprint Review

4. Sprint Retrospective

5. The Sprint

   
   

Sprint Planning The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following: 

• What can be delivered in the Increment resulting from the upcoming Sprint?

• How will the work needed to deliver the Increment be achieved?

• What can be done this Sprint?

  
  

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint. 

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

How will the chosen work get done? Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice. 

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. 

Sprint Goal: The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;

• Quality goals do not decrease; and,

• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

I consider one of the worst habits a Scrum team can develop: allowing work to spill over from one sprint to the next. This happens when a team does not finish all of the product backlog items they’ve planned into a sprint and simply carry the work over into the next sprint.

To be clear: It will happen occasionally that a team doesn’t finish everything. In fact, it’s a good sign that it does happen sometimes because that means a team is being aggressive in what they plan rather than under-committing each time.

However, a Scrum Master and team should not take a careless attitude toward failing to finish. When they do, sprints become artificial and meaningless boundaries. Teams should feel a slight bit of pressure towards the end of a sprint.

If spill over is a problem for your team, there are a few things you should consider doing.

First, you need to break the habit. Encourage the team to plan its next sprint such that they can definitely finish everything. That is, go light and plan the next sprint conservatively.

Then, if things are going well, add more to the sprint.

Next, make sure the team feels just a little bit guilty when they don’t finish everything. You don’t want them to feel horrible. That’s not the point. You want them to feel a little bad and guilty.

Daily Scrum

Scrum seeks to efficiently use your time and resources and the Daily Scrum event is no exception. The Daily Scrum is time boxed to 15 minutes. Standing up is not compulsory. However, many teams find this a useful technique to keep the meeting short and to the point.

The Daily Scrum is an opportunity for the Development Team to check in, assess progress towards achieving the Sprint Goal and to review and plan their activities for the next 24 hours.

This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity. 

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a selforganizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. 

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal.  Some Development Teams will use questions, some will be more discussion based. 

Here is an example of what might be used:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?

• What will I do today to help the Development Team meet the Sprint Goal?

• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting. 

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Sprint Review

Look again at the above principle from the Agile Manifesto — “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” That principle alone sums up the reason behind our next two meetings, the Sprint Review and the Sprint Retrospective.

Both events take place at the end of the Sprint. The aim of Agile approaches is not necessary to get everything ‘perfect’ the first time around, but to improve continuously. These events help make that possible.

A Sprint Review usually takes place on the last day of the Sprint and allows you the opportunity to show the “done” Increment to stakeholders (customers, management and anyone else considered relevant and interested). As well as demonstrating working features produced during the Sprint, you’re also after useful feedback that can be incorporated the Product Backlog that may help guide the work for future sprints.

Sprint Retrospective

The final meeting in the Sprint is the Sprint Retrospective. This is when the Scrum team reviews what could be improved for future Sprints and how they should do it. The ethos of Scrum dictates that no matter how good the Scrum team is, there will always be opportunity to improve and the Sprint Retrospective gives the team a dedicated time in which to identify, discuss and plan this. The whole Scrum Team should take part including the Development Team, the Scrum Master and the Product Owner. The meeting should be a collaborative effort, just like the entire Scrum and Agile process.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. 

The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process. 

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;

• Identify and order the major items that went well and potential improvements; and,

• Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Scrum Artifacts.

A scrum artifact is simply a representation of value or work to be completed, which is well-defined and should be transparently visible to all team members. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

The three main artifacts that do result from the Scrum development process are the Product Backlog, the Sprint Backlog, and the Burndown Chart. 

Although if a question comes into your Scrum Master certification exam like what are the different Scrum Artifacts then according to Scrum Guide you have to answer Product Backlog, the Sprint Backlog, and Increment.

We will be discussing all of them in this section.

Remember Project artifacts are not limited they could be even more depending upon scope and complexity of a project.

Product Backlog

Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric.

Product Backlog has certain properties that differentiate it from a simple to-do list:

• an entry in the Product Backlog always add value for the customer.

• the entries in the Product Backlog are prioritized and ordered according to there readiness.

• the level of detail depends on the position of the entry within the Product Backlog.

• all entries are estimated.

The backlog needs regular attention and care - it needs to be managed carefully. At the start of the project the Scrum Team and its Product Owner start by writing down everything they can think of easily. This is almost always more than enough for a first sprint.

After this initial setup, the Product Backlog has to be maintained in an ongoing process that comprises the following steps:

As new items are discovered they are described and added to the list. Existing ones are changed or removed as appropriate.

The most important items are moved to the top.

Preparing the high-priority stories for the next Sprint Planning Meeting

(Re-)Estimating the user stories in the Product Backlog

The Product Owner is responsible for making sure that the Scrum Product Backlog is in good shape again this is a collaborative process. When using Scrum Framework about 10% of the Scrum Teams total time should be reserved for maintaining the Product Backlog like discussion, estimation etc.

Product Backlog management includes:

• Clearly expressing Product Backlog items;

• Ordering the items in the Product Backlog to best achieve goals and missions;

• Optimizing the value of the work the Development Team performs;

• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,

• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realising the Sprint Goal.

The Sprint Backlog is a forecast by the Team about what functionality will be made available in the next Increment and the work needed to deliver that functionality as a working product Increment.

The Sprint Backlog is a plan with enough detail that can be understood and tracked in the Daily Scrum.

The Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Team can change its Sprint Backlog during a Sprint.

The Sprint Backlog is a highly visible, real-time picture of the work that the Team plans to accomplish during the Sprint, and it belongs solely to the Team.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint combined with the increments of all previous Sprints.

At the end of a Sprint, the new Increment must be a working product, which means it must be in a useable condition. It must be in working condition regardless of whether the Product Owner decides to actually release it.

The Scrum Team needs to have consensus on what is considered to be an Increment. This varies significantly per Scrum Team, but, team members must have a shared understanding of what it means for work to be complete. This is used to assess when work is complete on the product Increment.

The same understanding guides the Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality.

Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to release it immediately. If the understanding of an increment is part of the conventions, standards, or guidelines of the development organisation, all Scrum Teams must follow it as a minimum. If it is not a convention of the development organisation, the Scrum Team must define a definition of Increment appropriate for the product.

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their definitions of Increments expands to include more stringent criteria for higher quality. Any one product should have a definition of Increment that is a standard for any work done on it.

Sprint Burn-Down Chart

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Team tracks this total work remaining every day in Daily Scrum to project the likelihood of achieving the Sprint Goal.

By tracking the remaining work throughout the Sprint, the Team can manage its progress.

Sprint Burn-Down Chart is a practice for trending the work done by the Scrum Team. This has been proven to be a useful technique in monitoring the Sprint progress towards the Sprint Goal.

The Sprint Burndown Report shows the progress within the Sprint toward reaching the Sprint Goal. It provides transparency about the current performance (burndown rate) and allows easy estimation if the Sprint Goal can be reached in time or not.

Congratulation on finishing your Scrum Master Certification Course. Please take both mock tests.

Make sure you complete them 2 to 3 times until you have full confidence and get more than 95% in each.

I wish you good luck with your Scrum Certification exam.

Scrum Exercise to understanding why its is important to include user of the product while development.