Refresher for SM & PO

Sunday, 5 July 2020 12:19 AM

• Agile Blog
• Practice Exams
• Mainframe Blog
• MS Office Blog
• Register/Login
• Contact Us
Scrum Refresher Course for SM & PO
Rate this

Scrum Refresher: Scrum is a lightweight yet incredibly powerful set of values,

principles and practices. Scrum relies on cross­functional teams to deliver products and
services in short cycles, enabling:

• Fast feedback
• Continuous improvement
• Rapid adaptation to change
• Accelerated delivery
What is Agile?
Agile is a time boxed, iterative approach to software delivery that builds software incrementally
from the start of the project, instead of trying to deliver it all at once near the end. It works by
breaking projects down into little bits of user functionality called user stories, prioritizing them,
and then continuously delivering them in short two week cycles called iterations.
 • User stories: User stories are features our customers might one day like to see in their
software. They are written on index cards to encourage face­to­face communication.
Typically no more than a couple days work, they form the basis of our Agile plans. We get
them by sitting down with our customers and asking lots of questions.
• Iteration: It is a short one to four weeks period where a team takes their customers most
important user stories and builds them completely as running­tested­software.
Agile principles and values foster the mindset and skills businesses need in order to succeed in
an uncertain and turbulent environment. Agile Principle states the best architectures,
requirements, and designs emerge from self­organizing teams.

Refer to this video tutorial for more on Agile Product Ownership in a Nutshell.

What Is Agile Manifesto?

The Agile Manifesto is a brief document built on 4 values and 12 principles for agile software
development.

The Agile Manifesto also outlines 4 values for agile development practices.

1. Individuals and interactions over processes and tools: Helps in reducing conflicts among
Agile teams.
2. Working software over comprehensive documentation: Good face­to­face
communication supplemented by lean but sufficient documentation. The team should
determine what level of documentation is appropriate and produce just enough
documentation.
3. Customer collaboration over contract negotiation: Focus on what we are trying to build
with our vendors, rather than debating the details of contract terms. Scrum Teams deliver
products iteratively and incrementally, maximizing opportunities for feedback. So to
maximize the value of the delivered product regular and frequent feedback from the
customer is essential.
4. Responding to change over following a plan: Changes are accepted at any time during
the development effort depending on the business value of the change, the Product
Owner’s acceptance, and the ability of the team to respond in a timeframe acceptable to
the Product
The Agile Manifesto also outlines 12 principles for agile development practices.

1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face­to­face conversation.
7. Working software is the primary measure of progress.
 8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self­organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
What Is Scrum?
Scrum is an iterative incremental framework within which people can address (develop, deliver,
and sustain) complex adaptive products. At the same time, they can deliver products of the
highest possible value in a productive and creative manner.Scrum is not a process, technique,
or definitive method. Agile software development with Scrum is often perceived as a
methodology; but rather than viewing Scrum as methodology, think of it as a framework for
managing a process with short cycles.

Few benefits of short cycles are

• Fast feedback
• Continuous improvement
• Rapid adaptation to change
• Accelerated delivery
Scrum helps businesses:

• Innovate faster
• Move from idea to delivery more quickly
• Drive higher customer satisfaction
• Increase employee morale
What are the difference Between Scrum & Agile?
The difference between agile and Scrum is that agile refers to a set of principles and values
shared by several methodologies, processes and practices; Scrum is one of several agile
frameworks–and is the most popular.

What are the Characteristics of Scrum?

Scrum is:

• Lightweight framework: Scrum is a lightweight framework. It comprises of the rules and

practices that are few in number and easy to follow.
• Simplicity: One unique identity of Scrum is that it is simple to understand. This makes the
framework easy to comprehend even for the beginners.
• Difficult to master: There is a big difference between understanding Scrum and
implementing it in real­time projects. It is therefore somewhat difficult to master Scrum.
You need to practice in real time and learn the concepts in­depth. While working with
Scrum, one should properly understand why each component is in place, how it delivers
value as a discrete element, and also in relation to the other elements.
What are the Application Areas of Scrum?
Scrum was originally developed to organize and develop products. Scrum is now broadly used
for all the services, products, and in managing the organizations.
 1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on­demand) and other operational
environments for product use; and,
5. Sustain and renew products.
What is Scrum Theory?
Scrum is based on the theory of empirical process control, which relies on transparency,
inspection, & adaptation. Scrum is also both iterative and incremental.

Iterative: A process for arriving at a decision or a desired result by repeating rounds of analysis
or a cycle of operations. The objective is to bring the desired decision or result closer to
discovery with each repetition (iteration).1

Scrum’s use of a repeating cycle of iterations is iterative.

Incremental: A series of small improvements to an existing product or product line that usually
helps maintain or improve its competitive position over time. Incremental innovation is
regularly used within the high technology business by companies that need to continue to
improve their products to include new features increasingly desired by consumers.1

The way Scrum teams deliver pieces of functionality into small batches is incremental.

What are the Three Pillars of Empirical Process Control?

Transparency: To make decisions, people need visibility into the process and the current state
of the product. To ensure everyone understands what they are seeing, participants in an
empirical process must share one language.

Scrum Reviews Provide Transparency.Scrum’s frequent reviews give team members and
stakeholders a clear view into the state of the project.

Inspection: To prevent deviation from the desired process or end product, people need to
inspect what is being created, and how, at regular intervals. Inspection should occur at the
point of work but should not get in the way of that work.

Scrum Reviews & Retrospectives Offer Inspection Opportunities. Scrum teams inspect their
completed work and their process at the end of every iteration during the sprint reviews and
sprint retrospectives.

Adaptation: When deviations occur, the process or product should be adjusted as soon as
possible.

Scrum Teams Can Adapt the Product at the End of Every Sprint. Scrum allows for adjustments at
the end of every iteration.
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
What is Scrum Framework?
Scrum is a process framework that allows addressing complex problems to deliver products of
the highest possible value. The Scrum framework consists of the Scrum teams with associated
Scrum Roles, Scrum Ceremonies, Scrum Artifacts, and Scrum rules. Scrum organizes projects
using cross­functional Scrum Teams, each one of which has all of the capabilities necessary to
deliver a piece of functionality from idea to delivery.

What are the Scrum Values?

A team’s success with Scrum depends on five values: commitment, courage, focus, openness
and respect.

Commitment: People personally commit to achieving the goals of the Scrum Team.

ScrumMasters reinforce a team’s commitment when they facilitate sprint planning, protect
teams from mid­sprint changes, and deflect excessive pressure from product owners.

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

Great ScrumMasters help foster team courage by creating safety for team members to have
difficult conversations–with one another, with the product owner, and with stakeholders.
ScrumMasters are fearless about removing impediments that slow the team down.
ScrumMasters also stand up to stakeholders to prevent changes or side projects during the
sprint while also helping teams adapt when priorities shift between sprints.

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

ScrumMasters encourage team focus by holding the team to their own definition of done, by
encouraging full team participation at each daily scrum, and by ensuring that team members
only present work that is complete at the sprint review.

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

ScrumMasters facilitate openness in daily scrums so the team is always aware of exactly how
the sprint is going. ScrumMasters encourage openness in sprint reviews by ensuring that
stakeholder feedback is constructive and that team members are able to hear it. ScrumMasters
remind teams that learning about product shortcomings early is much less expensive and much
more helpful than hearing about them late in the project, or worse, after the product is in
customer’s hands. In the same way, ScrumMasters foster an open environment in sprint
retrospectives so that teams can grow and develop from sprint to sprint.

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

Courage: ScrumMasters develop respect in their teams. They help teams listen to each other
during daily scrums. They encourage teams to share their struggles and their successes.
ScrumMasters also point out times of strong collaboration and facilitate conversations around
new ideas.

How Scrum works and why it is importance?

• Software development in Scrum starts with a prioritized list of features­ Product Backlog.
The team discusses on:
○ The backlog
○ What is not yet completed
○ The duration required to complete the task.
• Sprint is the heart of Scrum and has the following features­
○ The goal of each Sprint is to create a quality product.
○ Each Sprint ends with a Sprint Review.
○ Once the first Sprint is over, the team selects the work items to develop a new
Sprint.
○ Sprint is continued till the project deadline is met.
○ Sprint is a time­boxed activity when the actual product is developed.
○ The duration of Sprint is from one week to one month to finish items from the
product backlog.
• In daily Scrum, teams meet to discuss the progress of the work.
○ The Daily Scrum should be no longer than 15 minutes.
○ Each team member should be prepared to discuss the status of the work.
○ The Scrum Master facilitates the meeting for the team members to achieve the
common goal.
What are the Benefits of using Scrum?
A perfect enabler for organizations, Scrum offers listless benefits to its users. The most
important ones are discussed below­

• Scrum makes frequent collaboration among the team members that leads to
interpersonal relationships and trust among them.
• Completion of work using the definition of done addresses the development, integration,
testing, and documentation with production.
• Conducting daily Scrum retrospective allows the Scrum teams to improve the efficiency of
work with Scrum factors.
• Providing quick delivery of software product in short iterations.
• Updating and reviewing according to the client’s requirements.
• Simple in understanding but following the process may be difficult.
• Involving in the sprint review meetings with stakeholder improves the team output.
What are the Scrum Best Practices?
The development team can create quality products by following the Scrum practices mentioned
below:
 • Define requirement ‘just­in­time’ to keep the product features more relevant.
• Take Product Owner’s feedback daily.
• Regular Sprint Reviews should involve the Stakeholder
• The Scrum team should arrange an event called Sprint Retrospective to improve how they
work.
• Arranging offline meetings to carry out face­to­face conversations.
• Don’t burn out the team members.
• Trust the team members.
• Respect the balance between the team members’ personal and professional lives to ease
the work.
What Is a Sprint?
Scrum Teams work in short timeframes called sprints. It is the heart of Scrum with short regular
iterations with no longer a bigger time­box of 2­4 weeks. Sprints happen one right after the
other, with no breaks, to maintain a steady project cadence. A new Sprint starts immediately
with the efforts of the development team after the conclusion of the previous Sprint.

Uncertainty can impact sprint length as it can come in a variety of forms: Requirements are not
well defined; technology is new and potentially risky; an algorithm or interface may be difficult
to implement. Similarly, stakeholder engagement and the timelines for the product release to
market can impact the sprint length. Holidays or planned vacation should not impact sprint
length. Also 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. The team
should agree on the length of the Sprint, taking the size and complexity of the project into
consideration. So below are few key factors are considered during deciding sprint length.

• The level of uncertainty over the technology to be used by the scrum team while
developing the work product.
• The risk of being disengaged from the stakeholders during the execution of the work
product.
• The ability and timeline to go market with the product release.
Key features of a sprint

• Time­boxed
• Establishes a WIP Limit
• Forces Prioritization
• Demonstrates Progress
• Avoid Unnecessary Perfections
• Motivates Closure
• Improves Predictability
• Short Duration
• Ease of Planning
• Fast Feedback
• Improved Return on Investment.
Few benefits of consistent sprint lengths are

• It helps to establish a consistent pattern of delivery.

 • It helps the team to objectively measure progress.
• It provides a consistent means of measuring team velocity.
Each sprint begins with a plan and ends with a review of the work completed and an additional
review of the way in which the team worked together.

During each sprint, the entire Scrum Team works together to complete one or more increments
of a larger overall product or project. Each completed increment must be potentially releasable,
meaning that it could theoretically be delivered as is. In other words, each increment must be
fully tested and fully approved by the end of the sprint.

What happens when a Sprint is cancelled?

The Product owner is responsible for canceling the Sprint under the influence of the
stakeholder, development team or the Scrum master.

• The Sprint cancellation can be done before the time­box is completed.

• It can also be done when the Sprint goal becomes obsolete. This might occur if the
company changes direction or if the market or technology conditions change
When a Sprint is canceled, 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.

How Do Sprints & Increments Allow Scrum Teams to Inspect and Adapt?
The idea is to deliver small batches of functionality that stakeholders can see and inspect at the
end of every Sprint. Then, based on that feedback, the Scrum Team can adapt their plans for
the next batch of functionality. By learning early what works and what doesn’t and whether an
increment matches stakeholder expectations, the Scrum Team is ultimately able to deliver a full
product that both satisfies and also delights customers.

How Do Sprints Reinforce the 3 Pillars of Empirical Process Control?

Remember that the 3 pillars of empirical process control are transparency, inspection, and
adaptation. Breaking work into short timeframes increases the number of opportunities for the
Scrum Team (including the product owner) to inspect the product and adapt what is built
moving forward. A traditional 6­month waterfall project typically has only 1­2 stopping points,
milestones, where the stakeholders can inspect the work–and very limited and expensive
chances to adapt.

A 6­month project using an agile framework like Scrum, however, typically has 6­12
opportunities to inspect and adapt the work, depending on how long each sprint is.

These end­of­each­sprint opportunities to inspect and adapt also increase transparency

because stakeholders and senior management are invited to view and give feedback on what is
being created at the end of every sprint, which translates into as often as every week or at
worst every month.

For more on the theory behind Scrum’s inspect and adapt and empirical process control
activities, see Scrum Theory.
Though Scrum began as a way to develop software, Scrum is currently used in a variety of
industries to successfully deliver all kinds of work products; see Benefits.

What are the Scrum Roles and what is a Scrum Team?

Scrum defines three roles: ScrumMaster, Product Owner, and Development Team. The Scrum
Team has two essential characteristics:

• Self-organized: The Scrum Team manages its own efforts rather than being managed or
directed by others. However, management and specialist efforts are not separated in
Scrum.
• Cross-functional: Cross­functional teams have all expertise and competencies needed to
accomplish the work without depending on others not part of the team.
These two characteristics are designed to optimize flexibility, creativity, and productivity,
needed for the Agile environment of Scrum.

There can be an individual who will test, code, analyze, do documentation, and so on, so there
are no separate roles apart from the above three predefined roles.

The presence of trust is positively correlated with team performance & motivation. When the
values of commitment, courage, focus, openness, and respect are embodied and lived by the
Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and
build trust for everyone. The Scrum Team members learn and explore those values as they
work with the Scrum events, roles, and artifacts.

Agile is an incremental and iterative approach, specialists can cause problems for such teams.
Sometimes, they make it difficult to maintain a balance between the types of work done by the
team. Members from Development Teams with an interest in the required domain stepping up
to take on any specialist work.

What is the significance of Product Owner role in Scrum?

The Product Owner called as Value Optimizer, Product Marketplace Expert and Lead Facilitator
of Key Stakeholder Involvement. Product Owner is responsible for optimizing Return on
Investment and Total Cost of Ownership for the Development Team’s work. Value is measured
by frequent delivery of Increments of the product into the market as market reception is the
best measure of value. Sole person responsible for managing the Product Backlog.

Product Backlog management is an ongoing activities includes:

• Clearly expressing Product Backlog items.

• Ordering the items in the Product Backlog to best achieve goals and missions of the
organization.
• Optimizing the value of the work the Development Team performs in each Sprint.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
the Scrum Team will work on next.
• Ensuring the Development Team understands items in the Product Backlog to the level
needed.
The items will be sorted based on their value, so less valuable and unclear items at the bottom
of the Product Backlog. The Product Owner may do the above work, or delegate some of
his/her responsibilities to the Development Team. However, the Product Owner remains
accountable.

Product Owner Attributes

• Empowered: Has decision­making authority for the product.

• Business-savvy: Knows the business, the customer and the market.
• Persuasive: Able to work well with the team and the stakeholders.
• Knowledgeable: Knows the market and the product. Grasps production challenges.
• Available: Is readily accessible to the team and to the stakeholders.
Product Owner Functions

• Customer Voice: Represents the customers wants and needs.

• Communicator: Knows how to tailor a message to a wide variety of stakeholders
• Decider: Sifts through competing priorities to choose the right product features and says
no to the rest.
The Product Owner is one person, not a committee. The Product Owner may represent the
desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. A
Product Owner’s decisions might be influenced by others, but he/she must have the final
say.The Product Owner’s decisions are visible in the content and ordering of the Product
Backlog. No one even the CEO can force the Development Team to work from a different set of
requirements.

Product Owner does not need to have application area knowledge of the project; they are
focused on the business aspect.

Product Owner should communicate effectively with the customers, stakeholders, and asks for
their input and expectations to use the information to keep the Product.

Product Owner is responsible for the monitoring remaining work towards the Sprint Goal and
Product Vision. This can be done by any projective practice based on trends of work completed
and upcoming work

Product Owner and Development team collaborate often so the Product Owner can make
informed decisions in balancing effort, scope versus schedule trade­off decisions and value of
Product Backlog items and Development teams can build Increments keeping end­user and
stakeholder concerns in mind.

What is the significance of Scrum Master role in Scrum?

The primary accountability of the scrum master is to provide delivery leadership, experience
and expertise by managing the scrum process, improving their organization’s ability to deliver a
valuable, relevant product. Also ensures that the Development Team understands and uses
Scrum correctly, the Scrum Master also tries to remove impediments to the Development
Team, protect the team from both internal and external distractions, facilitates their events,
and trains or coaches them.

The Scrum Master is a management position, which manages the Scrum process, rather than
the Scrum Team. He/she is a servant­leader for the Scrum Team.

Scrum Master Attributes

• Humble: Credits the team, not themselves.

• Respectful: Treat others as whole, creative, and purposeful beings with positive intent.
• Empathetic: Listens to understand. Is comfortable with silence.
• Persuasive: Works to remove impediments throughout the organization.
• Collaborative/Connected: Knows who to talk to (or finds out) to solve problems and
resolve issues.
• Transparent: The Scrum Master also promotes transparent communication outside of the
Scrum team. Without transparency, it is difficult for the organization to inspect and adapt
to achieve its desired business results using Scrum.
Scrum Master Functions

• Coach: Facilitates meetings, conversations, and improvements.

• Protector: Runs interference so the team can remain focused.
• Servant Leader: Leads without authority and puts the team first. Key qualities are
Listening skills, Empathy, Cultivating a culture of trust, Acting with humility, Encouraging
others.
• Agile Advocate: Reinforces agile principles throughout the organization.
• Impediment Remover:The Scrum Master holds responsibility for removing impediments,
mainly the project blockades that impede progress.
• Process Authority: Ensures that the team enacts and adheres to the scrum values,
principles, and practices alongside the specific approaches of the Scrum team.
Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum
Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog
items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize
value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:
 • Coaching the Development Team in self­organization and cross­functionality;
• Helping the Development Team to create high­value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not
yet fully adopted and understood.
Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Scrum adoption;

• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product
development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of
Scrum in the organization.
What is the significance of Development Team in Scrum?
The Development Team consists of professionals who do the work of delivering a potentially
releasable Increment of “Done” product at the end of each Sprint.Development Teams are
structured and empowered by the organization to organize and manage their own work. The
resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

• They are self­organizing. No one (not even the Scrum Master) tells the Development Team
how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross­functional, with all the skills as a team necessary to create
a product Increment;
• Scrum recognizes no titles for Development Team members, regardless of the work being
performed by the person;
• Scrum recognizes no sub­teams in the Development Team, regardless of domains that
need to be addressed like testing, architecture, operations, or business analysis; and,
• Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole.
Development Team Attributes

Pair programming: Work in collaboration with another one at the same workstation. One
programmer (the driver) writes the code and the other one (the navigator) reviews each line of
the code.

TDD, BDD: Advanced techniques of using automated unit tests to drive the design software and
get rid of dependencies in the team.

Self­motivation:It is the biggest driver of efficiency,

Team player: Every person in the team should be more of a team player and less of an
individual team member.

Development Team Functions

Sprint Execution: Performs the tasks of designing, building, integrating, and testing product
backlog items into increments of potentially shippable functionality.

Inspect and Adapt: In Daily Scrum team collectively inspect their progress toward the sprint
goal and adapt the plan for the current day’s work.In the sprint review, just­completed features
of the current sprint is reviewed and discussed how to progress in an efficient way. The sprint
retrospective is where the team inspects and adapts its Scrum process and technical practices
to improve the way it uses Scrum to deliver the best business value.

Product Backlog Grooming:This includes creating and refining, estimating, and prioritizing
product backlog items. In every sprint, the development team should allocate up to 10% of its
overall capacity to assist the product owner with all these activities.

Sprint Planning: Helps in establishing the goal for the sprint. Also team determines a high­
priority subset of the product backlog items which they should build to achieve that goal.

Development Team Size

The ideal size for a development is between 3 and 9 people. Ideally, it should be small enough
to remain ‘agile’ and large enough to complete a significant amount of work within a specific
Sprint.

In smaller team the number of interactions happening will be less, and this will naturally result
in low productivity. Very small Development Teams may often encounter skill constraints
during the ongoing Sprint. In such cases, they fail to deliver a potentially releasable Increment.

In larger team, communication becomes complex and cumbersome leads to coordination

problems.

The Product Owner and Scrum Master roles are not included in Development Team count
unless they are also executing the work of the Sprint Backlog.

What are the Scrum Events?

Scrum defines four events/ceremonies: Sprint Planning, Daily Scrum, Sprint Review, and Sprint
Retrospective. As per the scrum guide Sprint is also considered as an event which is a container
of the above four events.

What are the Leadership styles?

Agile Leadership contains
Focus on the people: Ask your Product Owners & Scrum Masters what you can do to help them
grow in their role

Dare to let go: Ask your Scrum Team what incentives could lead to a higher focus on customer
value.

Lead by example: Ask your Scrum teams and fellow­leaders how do they perceive the 5 Scrum
values in your organization.

Avoid shortcuts: If you want fast adoption and growth, hire external expertise and create a
setting where people can fail and learn fast.

Growing in the same pace causes less tension:Ask your Scrum team what organizational
limitations keeps them from making decisions as a whole.

Scrum Masters are called as Servant Leader. Servant Leadership comes when

• Focus on building a foundation of trust

• Stimulates empowerment and transparency
• Encourages collaborative engagement
• Is an un­blocker & empathic person able to truly listen
• Show ethical & caring behaviour putting others needs first
• Is humble, knowledgeable, positive, social and situationally aware
What is Sprint Planning?
The work to be performed in the Sprint is planned at the Sprint Planning. Sprint Planning is a
time­boxed meeting, usually fixed to 8 hours for a one month Sprint, or shorter for Sprints of
less than a month.This planning is done by the whole scrum team collaboratively.

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?
In the first part of this meeting addressed below mentioned items

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
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.

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.
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.

In the first part of this meeting addressed below mentioned items

The Product Backlog items selected for this Sprint plus the plan for delivering them is called the
Sprint Backlog. 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 Product Owner can help to clarify the selected Product Backlog items and make trade­
offs.The Development Team may also invite other people to attend this meeting 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.

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.

What is Capacity­Based Sprint Planning?

Capacity­based sprint planning, also called Commitment­based Sprint planning, is based on the
team’s available capacity (in hours) for the sprint and tries to fill that capacity effectively
without overburdening or under committing the team members.

Key benefits are

• The capacity of the teams may vary from one sprint to another, depending on holidays,
leaves, or other commitments. So, every sprint is not an average sprint.
• The story points and the velocity are the two important measures over multiple sprints for
estimating the release dates. But story points are found to be coarse­grained for planning
the details of a two­week sprint. If you consider the hours, they are fine­grained enough
and much useful for estimating concrete tasks.
• Lastly, in the Sprint Planning, the user stories allow the development team and the
Product Owner to consider each story in detail to develop a shared understanding of the
end product.
What is Velocity­Based Sprint Planning?
Velocity­based sprint planning uses velocity which helps the team to identify how much
progress they can aim to make in a given sprint. Velocity is calculated by adding all the story
points given to each user story that is completed by the end of the sprint. It measures output,
but not the outcome.

Key benefits are

 • Accounts uncertainty in planning – Since size of a user story is a mixture of effort and
uncertainty this method takes uncertainty into account while planning.
• Effective release planning – The detailed sizes of the stories can lead to a more value
added release planning with the identified dependencies/assumptions and their impact
over the release flow.
• Accounts overhead within the user story – velocity driven commitment encourages
through the completion of the story in all the aspects. When team inspects to increase the
velocity, they will point out the waste that is affecting the velocity most and the
stakeholders can work on it.
• Enforces a culture of honoring the commitment – After a few sprints of achieving the
commitment, the team gets used to it and the culture causes the team to actively reduce
waste or inspect their own development processes triggering the continuous
improvement.
What is Daily Scrum?
The Daily Scrum is normally a 15 minute meeting for the Development Team to inspect the
work since the last meeting, and synchronize their work and plan for the next 24 hours. It is an
opportunity 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 is held at the same time and place each day to reduce complexity.The Scrum
Master ensures that the Development Team has the meeting, but the Development Team is
responsible for conducting the Daily Scrum.

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.

Below given sample format for daily scrum but not mandatory format

• 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?
What is Sprint Review?
Sprint reviews held at the end of the Sprint to inspect the Increment and adapt the Product
Backlog if needed. Primarily focused on the product being developed, specifically on the
potentially shippable product increment created during the sprint. During the Sprint Review,
the Scrum Team and stakeholders collaborate about what was done in the Sprint.

This is at most a four­hour meeting for one­month Sprints. For shorter Sprints, the event is
usually shorter. The Product Owner has the option to release any of the completed
functionality.

The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been “Done” and what has
 not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran
into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions
about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely
target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what
is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product
Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet
new opportunities.

What is Sprint Retrospective?

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a
plan for improvements to be enacted during the next Sprint. Only Scrum team attend this
meeting.

This is at most a three­hour meeting for one­month Sprints. For shorter Sprints, the event is
usually shorter.

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.
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.

What are the Scrum Artifacts?

Scrum defines three artifacts: Product Backlog, Sprint Backlog, and a potentially releasable
product increment. Artifacts defined by Scrum are specifically designed to maximize
transparency of information related to the delivery of the project, and provide opportunities for
inspection and adaptation. Definition of “Done” is part of Artifact Transparency.

What is Product Backlog?

The Product Backlog is arranged in an ordered list of prioritized features that are needed as a
part of the end product.It is ordered based on their value so the highest priority items will be
on top. Higher ordered Product Backlog items are usually clearer and more detailed than lower
ordered ones.

The Product Backlog is dynamically changing and improving; it is never complete. It is a living
 artifact, changes in business requirements, market conditions, or technology may cause
changes in the Product Backlog.The Product Backlog evolves as the product and the
environment in which it will be used evolves. The Product Owner is responsible for the Product
Backlog, including its content, availability, and ordering.

The Development Team is responsible for all estimates. The Product Owner may influence the
Development Team by helping it understand and select trade­offs, but the people who will
perform the work make the final estimate.

What is Sprint Backlog?

The Sprint Backlog contains

• A number of items selected from the top of the Product Backlog, based on their estimated
work and the estimated capacity of the Development Team
• The Sprint Goal, which will help describe the real meaning of the items and direct the
efforts of the Development Team
• A detailed plan for delivery of the items and realization of the Sprint Goal during the
Sprint
To ensure continuous improvement, it includes at least one high priority process improvement
identified in the previous Retrospective meeting. The Development Team modifies the Sprint
Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This
emergence occurs as the Development Team works through the plan and learns more about
the work needed to achieve the Sprint Goal.

As new work is required, the Development 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 but to drop any planned items they must negotiate
it with the Product Owner. During this negotiation. Only the Development Team can change its
Sprint Backlog during a Sprint.

The Development Team tracks this total work remaining at least for every Daily Scrum to
project the likelihood of achieving the Sprint Goal.

Disclaimer: All the content related to Scrum Guide is taken from scrumguides.org and is under
the Attribution ShareAlike license of Creative Commons. Further information is accessible
at https://creativecommons.org/licenses/by­sa/4.0/legalcode and also described in summary
form at http://creativecommons.org/licenses/by­sa/4.0/.

Post navigation
← Business Analyst Interview Questions and Answers
Search for:

RECENT POSTS

• Scrum Refresher Course for SM & PO

• Business Analyst Interview Questions and Answers

• PSD Practice Assessment Random Mode Questions

• PSD Practice Assessment Real Mode Questions

• PSD Practice Assessment Practice Mode Questions

TOP RATED

• PSM Practice Exam Practice Mode Questions

• 108 Votes
• PSM Practice Exam Real Mode Questions
• 86 Votes
• PSPO Practice Exam Real Mode Questions
• 71 Votes
• PSM Practice Assessment Random Mode Questions
• 46 Votes
• Product Owner Interview Questions and Answers ­ Pa...
• 35 Votes
powered by ratingwidget
“PMP”, “PMBOK”, “PMI­ACP” and “PMI” are registered trademarks of the Project Management
Institute, Inc.
Professional Scrum Master, PSM, Professional Scrum Product Owner, PSPO etc. is the protected
brand of Scrum.org,
CSM, CSPO, CSD, CSP, A­CSPO, A­CSM are registered trademarks of Scrum Alliance.
• Facebook link
• Linkedin link
© 2020 TechAgilist. All rights reserved.
Developed by TechAgilist

From <https://www.techagilist.com/agile/scrum­refresher­course/>