Agile Business Consortium Scrum Master Workbook v5.0

Agile Business Consortium
Scrum Master Course
Learner Workbook
Copyright © 2019 Agile Business Consortium. All rights reserved
The APMG International Swirl Device logo is a trademark of The APM Group Limited, used under
permission of The APM Group Limited. All rights reserved.
YOUR LOGO HERE
My Learning Objectives for this Course
Agile Business Consortium Scrum Master P a g e |2 © 2019 Agile Business Consortium

YOUR LOGO HERE
Scrum and Roles Overview

YOUR LOGO HERE
Scrum
Scrum is a framework within which people can address complex adaptive

problems, while productively and creatively delivering products of the highest
possible value.
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
Scrum is a framework that has been used to manage complex product

development since the early 1990s. Scrum is not a process or a technique for
building products; rather, it is a framework within which you can employ various
processes and techniques. Scrum makes clear the relative efficacy of your product
management and development practices so that you can improve the product, the
Scrum Team performance, and the working environment.
The Scrum framework consists of Scrum Teams and their associated roles, events,
artefacts, and rules. Each component within the framework serves a specific
purpose and is essential to Scrum‟s success and usage.
The rules of Scrum bind together the events, roles, and artefacts, governing the
relationships and interaction between them.

YOUR LOGO HERE
Scrum Roles
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum
Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams
choose how best to accomplish their work, rather than being directed by others outside
the team. Cross-functional teams have all competencies needed to accomplish the work
without depending on others not part of the team. The team model in Scrum is designed
to optimize flexibility, creativity, and productivity.
Responsible for maximizing the value of the product resulting from

work of the Development Team
A servant-leader that does whatever it takes to make the Scrum

Team successful, such as removing organizational impediments,
facilitating Scrum events, protecting the team.
.
The professionals who do the work of delivering a potentially

releasable Increment of “Done” product at the end of each Sprint
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities

for feedback. Incremental deliveries of “Done” product ensure a potentially useful
version of working product is always available.

YOUR LOGO HERE
Scrum Master Responsibilities

• Promote and support Scrum as defined in the Scrum Guide by helping everyone
- Help everyone understand the Scrum theory, practices, rules and
values
- Interact in a way that helps maximise the value created by the
Scrum Team
• Provide service to the Product Owner by
- Ensuring that goals, scope, and product domain are understood by
everyone on the Scrum Team
- Finding techniques for effective Product Backlog management
- Supporting the Product Owner in understanding and practicing
agility
• Provide service to the Development Team by
- Coaching the Development Team in self-organization and cross-
functionality
- Removing impediments to the Development Team‟s progress
- Facilitating Scrum events as requested or needed
• Providing service to the Organization
- Leading and coaching the organization in its Scrum adoption
- Causing change that increases the productivity of the Scrum Team
- Working with other Scrum Masters to increase the effectivenessof
Scrum in the organization
Notes

YOUR LOGO HERE
Self Organisation

YOUR LOGO HERE
Self Organization Model
Based on: Glenda Eoyang: Conditions for Self-Organising in Human Systems
• C: Container. Any feature of the system that holds agents together until system-wide
patterns form can function as a system container. Large or loose containers leadto slow
and ambiguous self-organizing processes. Small, tight containers set conditions for
faster and clearer emergence.
• D: Difference. Diversity or energy that is important to the system can help to shape
patterns. Few or small differences contribute to slow and subtle pattern formation.
Many or large differences may contribute to disruptions that are apparently random.
• E: Exchange. The connections that transfer energy, information, or resources across
differences within a container are considered to be exchanges. Tight exchanges create
fast and predictable changes, while loose exchanges set conditions for slow and
unpredictable change
Notes

YOUR LOGO HERE
Designed Alliance
 A “container” that sets the context for expected team behaviors
 Created by the whole Scrum Team

 Participants commit to holding each other accountable to it
 Sets the foundation for healthy conflict
What would your team or organization be like if you lived up to that Designed Team Alliance
or working agreement every day?
Your Thoughts

YOUR LOGO HERE
Agile Fundamentals
Agile Business Consortium Scrum Master P a g e | 10 © 2019 Agile Business Consortium

YOUR LOGO HERE
It is said Scrum is simple to understand yet difficult to master. What else fits that definition?
Your thoughts

YOUR LOGO HERE
Agile Manifesto
The Agile Business Consortium believes that the values agreed in the Manifesto for Agile
Software Development are as applicable to the way businesses operate and change their
capabilities as they are to the way software is created and delivered. To this end, by
substituting „software‟ with „solutions‟ the scope of the manifesto itself can readily support
that wider cause.
The Agile Business Consortium are building on the

Manifesto for Agile Software Development
by uncovering better ways of
developing solutions to business problems and opportunities.
Through this work we continue to value:
Individuals and interactions over processes and tools

Working solutions over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while we value the items on the right,

we value the items on the left more.

YOUR LOGO HERE
Agile Principles
Principles behind the Agile Manifesto
We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer‟s
competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developments must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-
face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility
Simplicity – the art of maximizing the amount of work not to be done – is essential.
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 behaviour
accordingly.
Again, with a shift of emphasis away from the specifics of software for some of these principles, the
Agile Business Consortium believes that they have wider applicability in the world of business.
Our highest priority is to satisfy the customer through early and continuous delivery of value.
Welcome change, even late in the evolution of a solution. Agile processes harness change to
deliver competitive advantage.
Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
All parties involved in evolving valuable solutions must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
The most efficient and effective method of conveying information to and within any team is face-to-face
conversation.
Working solutions are the primary measure of progress.
Agile processes promote sustainable delivery, and everybody involved should be able to maintain a constant
pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity -- the art of maximizing the amount of work not done -- is essential.
The best understanding of problems and opportunities and the most successful business outcomes emerge
from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behaviour accordingly.

YOUR LOGO HERE
• Discuss the Agile Principles

• Agree in your table group the three most important the three least important
Your thoughts

YOUR LOGO HERE
Scrum Values
• People personally COMMIT to achieving the goals of the Scrum team

• Everyone FOCUSes on the work of the Sprint and goals of the Scrum team
• The Scrum Team and its stakeholders agree to be OPEN about all the work and the
challenges with performing the work
• Scrum team members RESPECT each other to be capable, independent people
• Scrum team members have COURAGE to do the right thing and work on tough problems
Notes

YOUR LOGO HERE
Empirical Product Development

YOUR LOGO HERE
Story Mapping: Jeff Patton
Story Mapping

YOUR LOGO HERE
Build up the solution piece by piece
Revisit previously worked-on process
For example… Building an online auction site:
 Incrementally: We‟d perfect creating accounts before starting on listing auction items
 Iteratively: We‟d build a little bit of all parts and then a little more of all parts and so on
Neither is all good alone…. But together, iterative and incremental are fantastic

YOUR LOGO HERE
Empirical Process Theory
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 accepting the work product must share a common
definition of “Done”.
Inspection
Scrum users must frequently inspect Scrum artefacts 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.

YOUR LOGO HERE
Shifting the focus on solution management
What are the benefits of this approach?

Where could you apply an incremental and iterative approach to developing products in
your organization? Are there any challenges? How would you address them?
Explain how evolutionary product planning in an empirical environment differs from
traditional fixed planning, and give an example of when each may be appropriate.
Your Thoughts

YOUR LOGO HERE
Reflection
Explain how evolutionary product planning in an empirical environment differs from
traditional fixed planning and give an example of when each may be appropriate.
Describe Scrum‟s relationship to the Agile Manifesto
Explain why Scrum is a framework and list two ways that a framework is different from a
methodology

YOUR LOGO HERE
Scrum Events

YOUR LOGO HERE
Time Boxes for Scrum Events
All Scrum Events are timeboxed (a defined period of time within which the activity must take
place) The timebox duration depends on the sprint length
Scrum Event Two week sprint (1 day) for Plan, One Month Sprint (2 days)
Review & Retro for Plan, Review & Retro
Sprint Planning 4 hours 8 hours

Daily Scrum 15 mins 15 mins
Sprint Review 2 hours 4 hours
Sprint Retrospective 1 to 2 hours 3 hours
Backlog Refinement
Backlog refinement is the activity of getting Product Backlog Items „Ready‟ for the
Development Team to take into Sprint Planning. This involves Clarifying, Splitting and
Estimating backlog items.
It is the Product Owner‟s responsibility to ensure Backlog Items are „Ready‟, however,
support from the Development Team to work ahead and refine the backlog items will be
required to ensure this happens effectively.
Refinement usually consumes no more than 10% of the capacity of the Development Team.
However, Product Backlog items can be updated at any time by the Product Owner or at the
Product Owner‟s discretion.
For Development Teams to be highly productive, backlog refinement is essential. Scrum
Masters should encourage this practice and support everybody in making it effective.

YOUR LOGO HERE
The Sprint Planning Event
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?

YOUR LOGO HERE
Sprint Planning Part 1 - What
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.
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 selected
subset of the Product Backlog, and it provides guidance to the Development Team on why it
is building the Increment.
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met
through the implementation of Product Backlog items. 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 what is implemented
within the Sprint. The Sprint Goal should provide a coherence of purpose 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. If the work needed to
achieve the Sprint Goal 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.

YOUR LOGO HERE
Sprint Planning Part 2 – How

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 enhanced product and the work
needed to convert the Product Backlog into a valuable 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 in order 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 Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a
forecast by the Development Team about what value will be delivered during the next Sprint
and the work needed to deliver a “Done” Increment.
The Sprint Backlog makes visible all of the work that the Development Team identifies as
necessary to meet the Sprint Goal.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood
in the Daily Scrum. 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. Only the Development Team can change
its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of
the work that the Development Team plans to accomplish during the Sprint, and it belongs
solely to the Development Team.

YOUR LOGO HERE
The Daily Scrum

 Daily timeboxed 15 minute meeting for the Development Team
 Purpose:
o Inspect work done over the last 24 hours
o Inspect progress towards the Sprint Goal
o Plan work for the next 24 hours
 To do this each team member might answer 3 questions:
o What did I do yesterday that helped the Development
Team meet the Sprint Goal?
o What will I do today to help the Development Team
meet the Sprint Goal?
o Do I see any impediment that prevents either me or the
Development Team from meeting the Sprint Goal?
 For Development Team synchronization and commitment
o Not a Scrum Master status meeting
o Not for problem solving - arrange a follow-on meeting for that
o Product Owner‟s participation invited by the Development Team
– normally a good idea
Making the daily Scrum effective
Your Thoughts

YOUR LOGO HERE
The Sprint
The heart of Scrum is a Sprint, a timebox of one month or less during which a “Done”,
useable, and potentially releasable product Increment is created. Sprints best 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 definition of what is to
be built, a design and flexible plan that will guide building it, the work, and the resultant
product.
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.

YOUR LOGO HERE
Potentially Shippable Product Increment
Product Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and
the value of the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be “Done,” which means it must be in useable condition and meet the
Scrum Team‟s definition of “Done.” It must be in useable condition regardless of whether
the Product Owner decides to actually release it.
Notes

YOUR LOGO HERE
Working in the Sprint
Rapid Cycle – minimal testing lag

YOUR LOGO HERE
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the
Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders
collaborate about what was done in the Sprint. Based on that and any changes to the
Product Backlog during the Sprint, attendees collaborate on the next things that could be
done to optimize value. This is an informal meeting, not a status meeting, and the
presentation of the Increment is intended to elicit feedback and foster collaboration.
This is a four-hour time-boxed 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 teaches all to keep it within the time-box.
The Sprint Review includes the following elements:
• Attendees include the Scrum Team and key stakeholders invited by the ProductOwner;
• 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” andanswers
questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projectslikely
completion 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 release 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.

YOUR LOGO HERE
Sprint Review Reflection

Identify at least 3 ways the Sprint Review differs from a traditional project progress
meeting
Discuss how the Sprint Review makes empirical process control (transparency, inspection
and adaptation) a reality
What techniques could the Scrum Master suggest to help keep the Sprint Review focused
and effective while serving both the Scrum Team and the wider organisation ?
Sample Agenda for a Sprint Review

Intro – The purpose of the meeting
Product Owner explains what Product Backlog items have been “Done” and what has not
been “Done”
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
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
Possible review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality or capability of the product.

YOUR LOGO HERE
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.
The Sprint Retrospective occurs after the Sprint Review and prior to
the next Sprint Planning. This is a three-hour time-boxed 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 timebox. 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
• 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 adapting the definition of “Done” as appropriate.
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.

YOUR LOGO HERE
Agile Retrospectives - Making Good Teams Great

Esther Derby and Diana Larsen
Other Resources
http://agile2007.agilealliance.org/downloads/handouts/Larsen_448.pdf
Agile Retrospectives Google tech talk video - http://video.google.com/videoplay?docid=-
7910406883328902493 Esther and Diana presenting to Google.
A website that provides a number of exercises to plan Retrospectives in the Agile
Retrospectives book format: http://www.plans-for-retrospectives.com/
Another website with lots of useful games for retrospectives and other games to do with
your teams http://tastycupcakes.org/

YOUR LOGO HERE
The Development Team

YOUR LOGO HERE
What characteristics, disciplines and skills would you expect to find in an effective self-
organising, cross-functional Development Team within your organization(s)?
Your thoughts

YOUR LOGO HERE
Team Size
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.
This affects communication overhead and group decision making. Relationships are key, maintaining
relationships takes time. The highest performing teams need to have strong relationships
Hackman and Vidmar Study on working group size,

a mixture of:
• Production (writing)
• Discussion
• Problem Solving
Two key questions:
• Was your group too small?
• Was your group too large?

YOUR LOGO HERE
The Development Team

Summary:
The Development Team should have:
– Between 3 and 9 members (excluding the PO and SM)
– All the skills required to turn product backlog items

into a „done‟ product increment
– A stable membership – with team

members changing only rarely
– Full time team members dedicated

to the work of the team
The Development Team:

– Collaborate as a team to complete Sprint Backlog
items
– Share knowledge of specialist skills; rotate common tasks
– Egos are put aside
The Scrum Master:
– Encourages, coaches, facilitates and helps remove obstacles to this critical element of
Scrum Product Development

YOUR LOGO HERE
Reflecting on Yesterday
 key takeaways from yesterday

 Is there anything we should change on the working agreement, based on behaviors you
observed yesterday?
 Do you want to take the opportunity to learn from others and form a new team, or continue
with the team members you have started to build relationships with?
Your thoughts

YOUR LOGO HERE
Scrum Context and Change

YOUR LOGO HERE
The Waterfall approach to software development was inspired by the approaches used to design and
development in engineering and construction. Royce proposed that the same concepts could be
applied to software but identified that the simplistic approach – similar in style but not wording to
the above diagram – was risky and invited failure because it did not allow for feedback. Using the
language from this course it was not iterative. In its simplistic form, it also aimed to deliver in a „big
bang‟…. Specify the whole thing, design the whole thing, develop the whole thing etc. and put it into
live use in a single big „deployment‟ event. Using the language from this course it was not
incremental. His paper went on to explain how to address these issues but in a way that was difficult
to understand. Ironically it was the simplistic, risky approach that became popular and is still causing
problems today. In reality, the bigger the project, the greater the risk and ultimately the cost of
failure turned out to be. It was the massively high failure rate that encouraged the creation of Scrum
and many other Agile approaches

YOUR LOGO HERE
Traditional Organizations and Scrum

Adam Smith is famous for on that “Division of labour in pin manufacturing and the increase in the
quantity of work that results”.
Much of this thinking has been carried into business more generally and, particularly in the last 30-40
years has led to the emergence of specialists in just about all disciplines of business. Small
companies rely on generalists – individuals who are multi-disciplinary e.g. people who can turn their
hand to all aspects of marketing, sales, customer service, finance etc. In extreme, think of a „man
with a bucket‟ window cleaner. He is responsible for all aspects of his business. Larger organisations
tend to rely on specialists, and often departments of specialists. Scaling up window cleaning to a
nation-wide business the man with the bucket would be one of thousands of men an women with
buckets – all exclusively responsible for cleaning windows and little else…. Head office would
probably have departments of people responsible for their own specialisms e.g. marketing the
services of those who clean the windows; procuring the buckets, ladders vehicles and consumables
used by those who clean the windows; Invoicing customers and collecting the money for services
rendered, dealing with complaints etc.
Scrum advocates the use of small self-organising multi-disciplinary teams capable of fulfilling the
needs of their customer…. A middle ground between the „one-man band‟ and the siloed organisation
of specialists

YOUR LOGO HERE
Scrum Timeline

YOUR LOGO HERE
Scrum and Traditional Processes
In many organisations, Scrum is often used only for the development of products. Much more value
to a business can be achieved by broadening the application of Scrum across multiple disciplines and
focus on rapid, efficient delivery of small product increments.
This can be achieved over time by e.g. bringing a bit more Design work into a sprint and/or a bit more
Quality Check activity. In the process above shifting „ready‟ for the Sprint to the left and „done‟ for
the Sprint to the right
„Ready‟ and „Done‟ will be described in more detail later in the course

YOUR LOGO HERE
Your Gated Process for Product Development

And where Scrum might be applied to it
Where you would start with Scrum in your organization
 What stakeholder behaviors support a Scrum Team‟s success

 What stakeholder behaviors will not support a Scrum Team‟s success
What benefits the organization would see from this approach
What organizational impediments can affect the effectiveness of a Scrum Team

What you could change short term, what would need longer term change
----- Sprint -----
Fill in your gated process. Where could you start with Scrum?

YOUR LOGO HERE
Living the Scrum Roles

YOUR LOGO HERE
Scrum Roles
(recap from day 1)
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum
Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams
choose how best to accomplish their work, rather than being directed by others outside
the team. Cross-functional teams have all competencies needed to accomplish the work
without depending on others not part of the team. The team model in Scrum is designed
to optimize flexibility, creativity, and productivity.
Responsible for maximizing the value of the product resulting from

work of the Development Team
A servant-leader that does whatever it takes to make the Scrum

Team successful, such as removing organizational impediments,
facilitating Scrum events, protecting the team.
.
The professionals who do the work of delivering a potentially

releasable Increment of “Done” product at the end of each Sprint
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities

for feedback. Incremental deliveries of “Done” product ensure a potentially useful
version of working product is always available.

YOUR LOGO HERE
Scrum Master
 Helps the Development Team become self-organised and

cross-functional
 Maximises the sustained output and quality of the
Development Team
 Assists the Scrum Team to continually improve
 Maintains the Scrum Team‟s motivation
 Coaches the Product Owner and Development Team in
the Scrum values, practices, and rules
 Educates others outside the Scrum Team about how the team
is working
 Removes impediments to the Development Team‟s progress
 Organizational change agent
 Facilitates Scrum Team‟s meetings
 Servant leader rather than manager
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those
outside the Scrum Team understand which of their interactions with the Scrum Team are
helpful and which aren‟t. The Scrum Master helps everyone change these interactions to
maximize the value created by the Scrum Team.
Scrum Master Service to the Product Owner

• Ensuring that goals, scope, and product domain are understood by everyone on the
Scrum Team
• 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
• 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.

YOUR LOGO HERE
Scrum Master Service to the Organization

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

YOUR LOGO HERE
Servant Leadership
The king [leader] shall consider as good, not
what pleases himself but what pleases his
subjects [followers]
The king [leader] is a paid servant and enjoys

the resources of the state together with the
people
Chanakya wrote, in the 4th Century, in his book,
Arthashastra
The highest type of ruler is one of whose existence

the people are barely aware.
Next comes one whom they love and praise. Next
comes one whom they fear.
Next comes one whom they despise and defy.
Relates to servant leadership in the Tao Te Ching,

attributed to Lao-Tzu, who is believed to have lived
in China sometime between 570 BCE and 490 BCE.
While servant leadership is a timeless concept, the phrase “servant leadership” was coined
by Robert K. Greenleaf in The Servant as Leader, an essay that he first published in 1970. In
that essay, Greenleaf said:
“The servant-leader is servant first… It begins with the natural feeling that one wants to
serve, to serve first. Then conscious choice brings one to aspire to lead. That person is
sharply different from one who is leader first, perhaps because of the need to assuage an
unusual power drive or to acquire material possessions…The leader-first and the servant-
first are two extreme types. Between them there are shadings and blends that are part of
the infinite variety of human nature.
“The difference manifests itself in the care taken by the servant-first to make sure that other
people’s highest priority needs are being served. The best test, and difficult to administer, is:
Do those served grow as persons? Do they, while being served, become healthier, wiser,
freer, more autonomous, more likely themselves to become servants? And, what is the
effect on the least privileged in society? Will they benefit or at least not be further
deprived?“
A servant-leader focuses primarily on the growth and well-being of people and the
communities to which they belong. While traditional leadership generally involves the
accumulation and exercise of power by one at the “top of the pyramid,” servant leadership is
different. The servant-leader shares power, puts the needs of others first and helps people
develop and perform as highly aspossible.

YOUR LOGO HERE
Product Owner
 Responsible for the Vision

 Responsible for the Product success
 Responsible for Return on Investment
 Decides on release date and content
 Manages stakeholders and interests proactively
 Defines customer value-added and the key features
of the product
 Sets development schedule by prioritising and
orderingthe Backlog
 Takes advice from the Development Team on Product
Backlog dependencies
 Accepts or rejects work results in the Sprint Review meeting
 Steers and guides the work, answers questions on a daily basis
The Product Owner is responsible for maximizing the value of the product and the work of the
Development Team. How this is done may vary widely across organizations, Scrum Teams, and
individuals.
The Product Owner is the sole person responsible for managing the Product Backlog.
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.
The Product Owner may do the above work or have the Development Team do it. However,
the Product Owner remains accountable.
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.
The Product Owner‟s decisions are visible in the content and ordering of the Product
Backlog. No one is allowed to tell the Development Team to work from a different set of
requirements, and the Development Team should not act on what anyone else says.

YOUR LOGO HERE
Product Owner Reflection
Discuss at least two reasons why the Product Owner is a single person and not a group or a
committee
Discuss how and why the Product Owner maintains authority over the product while working
collaboratively with the Development Team and stakeholders to gather their ideas, feedback and
input

YOUR LOGO HERE
Cancelling a Sprint
• Development Team can ask to abnormally terminate if….

- They cannot meet the Sprint Commitment
• Product Owner can abnormally terminate if…

- Business priorities change
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 has to regroup in another
Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the
Scrum Team and are very uncommon.

YOUR LOGO HERE
Development Team
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. Only members of the
Development Team create the Increment.
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 releasablefunctionality
• Development Teams are cross-functional, with all of the skills as a team necessary to
create a product Increment
• Scrum recognizes no titles for Development Team members other than Developer,
regardless of the work being performed by the person; there are no exceptions to this rule
• Scrum recognizes no sub-teams in the Development Team, regardless ofparticular
domains that need to be addressed like testing or business analysis; there are no
exceptions to this rule and,
• Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole.

YOUR LOGO HERE
What about other roles, like the Project Manager?
As a combined framework, AgilePM and Scrum offers a coherent solution to address many of
the problems associated with using an Agile approach to projects at scale and in more
conservative and/or more heavily regulated organizations.
The framework embraces a number of governing roles to ensure that regulatory and other
governance needs are addressed without damaging the essence of Agility.
There is virtually no impact on the Scrum Development Team whose members remain free to
embrace and exploit the full value offered by the collaborative, iterative and incremental
Scrum approach to product development.
Scrum requires the Product Owner to be the one person responsible for maximising the
value of the product and the work of the Development Team whilst, potentially, representing
the needs of many diverse stakeholders within the organization sponsoring the project. The
combined AgilePM and Scrum framework introduces roles, events and guidance for
interactions that help the Product Owner do this in larger and more complex organizations.
Through the same roles and events it also provides a more formal frame of reference and
sphere of influence within which the Scrum Master can fulfil the related responsibilities of
ensuring the Scrum Team adheres to Scrum theory, practices and rules and influencing the
wider organization to give the Scrum Team(s) the space they need to make Scrum truly
effective e.g. through self-organization and taking real responsibility for building a quality
product.
A combination of AgilePM and Scrum is unlikely to represent the whole solution to the
problem of exploiting an Agile project approach in more conservative organizations but it
represents a good start. Much attention will still need to be given to winning the hearts and

YOUR LOGO HERE
minds of sceptics across the organization, promoting the essential change of mind-set
needed in everybody to be Agile rather than just to allow “others” to do Agile.
All too often the first steps to the adoption of Agile approaches either fail or are fatally
compromised by the “bottom-up” approach to change where IT development teams try to
adopt Agile ways of working that fly in the face of entrenched organizational norms for
governance and control that simply cannot be ignored or circumvented. The combined
framework replaces the default “trust us, we know what we are doing” approach, that is so
often rejected, with a basis for integration of Agile project practices with the necessary
elements of corporate governance.
Finally, the combined framework provides a light but robust basis for scaling projects,
allowing the efforts of multiple Agile teams to be coordinated to deliver a single coherent
solution. This scaling is based on the proven ability of DSDM to do so and is formalised by the
Project Team roles and the new Project Planning event.
“Scrum is a very well-used approach for software development, but too few people
understand how to fit it into an effective project management framework. It is too easy either
to misapply Scrum under an over-bearing project management regime, or blindly run Scrum
and hope the project management will happen by itself. Both lead to trouble. For those who
believe there must be a better way, Andrew provides a practical and accessible guide. He
demonstrates how to open up Scrum to work with a proven framework for Agile project
management. The best of both worlds are maintained. This book is valuable for those
familiar with both areas, but also to those who are familiar with one and who want a taste of
how they can expand their horizons.”
Dr Nik Silver, Former Head of Technology Development Programme at Guardian News and
Media, Agile Consultant specialising in enterprise-scale Agile and Coach and Mentor to those
making the transition to Agile.

YOUR LOGO HERE
Roles Reflection
(after the course)
Consider the three roles in a Scrum Team and how they interact with each other to deliver
the product increment within a sprint.
Consider the disadvantages of shared roles in Scrum. Purely from a Scrum perspective (i.e.
not for reasons of pragmatism or convenience within your organisation) are there any real
advantages of shared roles
Consider what changes might be needed within your organisation to make Scrum roles truly
effective.

YOUR LOGO HERE
The Product Backlog

YOUR LOGO HERE
Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the product and
is the single source of requirements for any changes to be made to the product. The Product
Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it only lays out the
initially known and best-understood requirements. The Product Backlog evolves as the
product and the environment in which it will be used evolves. The Product Backlog is
dynamic; it constantly changes to identify what the product needs to be appropriate,
competitive, and useful. As long as a product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases. Product Backlog
items have the attributes of a description, order, estimate and value.
As a product is used and gains value, and the marketplace provides feedback, the Product
Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a
Product Backlog is a living artefact. Changes in business requirements, market conditions,
or technology may cause changes in the Product Backlog.
Multiple Scrum Teams often work together on the same product. One Product Backlog is
used to describe the upcoming work on the product. A Product Backlog attribute that
groups items may then be employed.
Notes

YOUR LOGO HERE
Product Backlog Funnel
D – Detailed Appropriately
The product backlog items are detailed appropriately if higher-priority items are described in
more detail than lower-priority ones.
E – Estimated
The product backlog items–certainly the ones participating in the next major release–should
be estimated. The estimates are coarse-grained and often expressed in story points or ideal
days. Knowing the rough size of the items helps prioritise them and track the progress of the
release.
E – Emergent
The product backlog has an organic quality: it evolves and its contents change frequently.
New items emerge based on customer and user feedback and are added to the backlog.
Existing items are modified, reprioritized, refined, or removed on a regular basis.
P – Prioritised
All items in the product backlog are prioritised (or ordered). The most important and
highest-priority items are implemented first.
Going DEEP, from Roman Pichler http://www.romanpichler.com/blog/make- the-product-

backlog-deep/

YOUR LOGO HERE
Product Backlog Refinement

Additional information
Product Backlog refinement is the act of adding detail, estimates, and order to items in the
Product Backlog. This is an ongoing process in which the Product Owner and the
Development Team collaborate on the details of Product Backlog items. During Product
Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when
refinement is done. Refinement usually consumes no more than 10% of the capacity of the
Development Team. However, Product Backlog items can be updated at any time by the
Product Owner or at the Product Owner‟s discretion.
Higher ordered Product Backlog items are usually clearer and more detailed than lower
ordered ones. More precise estimates are made based on the greater clarity and increased
detail; the lower the order, the less detail. Product Backlog items that will occupy the
Development Team for the upcoming Sprint are refined so that any one item can reasonably
be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the
Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.
Product Backlog items usually acquire this degree of transparency through the above
described refining activities.
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.

YOUR LOGO HERE
‘Ready’
A backlog item that is considered to be refined sufficiently to be ready for development is one that:
 Is well understood enough so that the Development Team can estimate effort to complete
 Is small enough for the Development Team to deliver with between three and nine other
Product Backlog Items in a Sprint
 Has had high-level solution design considered for that item (where appropriate)
 Includes sufficient supporting information and/or subject matter experts identified and
accessible as required to develop the item

YOUR LOGO HERE
User Stories
Format
A user story is a way of formatting a Product Backlog item
The format used is:
As a <USER ROLE>
In need <to achieve this GOAL>

So that <I can achieve this VALUE>
This structure describes who will benefit from fulfilling the story, what they need and why
they need it. Note that „I want‟ rather than „I need‟ is a more often used term but thinking in
terms of a need helps focus the story writers on the most valuable aspects of the product
increment being described.
The user Story format can be used to describe backlog items of all shapes and sizes. From
Epic Stories that need to be broken down as part of Backlog Refinement at some point in the
future (e.g. As a Brand Manager, I need new branding, so that our product will appeal to our
new target market) down to stories that are ‘ready’ for an upcoming Sprint (e.g. As a
Customer, I need to cancel a hotel booking, so that I can get a refund).
Structure
Mike Cohn described the structure of a story as including “The three Cs” of Card, Conversation and
Confirmation. The Agile Business Consortium have added a fourth C – for Context
A story is written on a card which is considered to be token for a conversation. Acceptance

criteria are written on the back of the card to help define „done‟ for the story and context
can be provided by visual models e.g. business process models or story maps

YOUR LOGO HERE
Acceptance Criteria
Story Slicing
The process of breaking stories down from larger stories to smaller stories

YOUR LOGO HERE
Story Slicing approaches:
http://agilecoach.typepad.com/agile-coaching/2010/09/ideas-for-slicing-user-stories.html
There is some good discussion at the bottom of this post
http://agilepainrelief.com/notesfromatooluser/2010/09/story-slicing-
how-small-is- enough.html
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.h
tml Patterns for Story slicing, also includes a cheat sheet
http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
http://xp123.com/xplor/xp0512/index.shtml
Bill Wake‟s (a bit of a celebrity in the Agile world ) 20 ways
to split stories http://lassekoskela.com/thoughts/7/ways-
to-split- user-stories/
A good PDF with a more structured approach to slicing stories:
http://www.stickyminds.com/measurementandreporting.asp?Function=edetail&ObjectType
=MAGAZINE&ObjectId=16239&tth=DYN&tt=siteemail&iDyn=1
INVEST in good stories
Bill Wake coined the acronym INVEST to describe a Story that is „Ready‟ for a Sprint
See http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ for details

YOUR LOGO HERE
Getting your first Product Backlog
Story Writing Workshops
• Participants include Product Owner, Development Team,

Stakeholders (Users, Customers and others)
• Brainstorm to generate stories
• Cover full scope of solution
• Some will be small and ready to implement
• Others will be epics
• No prioritization at this point
Activity List …..
• Review the Vision

• Generate User Roles
• Group Roles
• Generate Initial Stories
• Generate Features
These will also need to be done ….
• Identify medium term Goals
• Order User Stories within at least the first releases
• Estimate the whole backlog
• Initially Identify Minimal Marketable Features …. refine overtime!

YOUR LOGO HERE
Product Backlog Reflection
Notes

YOUR LOGO HERE
Sprint Planning
and
Done

YOUR LOGO HERE
Sprint Planning
Roles and Responsibilities
First confirm Sprint Goal and Definition of Done
Then discuss and accept backlog items into Sprint
Only the Development Team decides „enough‟

YOUR LOGO HERE
Sprint Goals – A Communication Tool
The Sprint Goal is an objective set for the Sprint that can be met through the
implementation of Product Backlog items. 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 what is implemented
within the Sprint. The Sprint Goal should provide a coherence of purpose 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. If the work needed to
achieve the Sprint Goal 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.
A sprint goal is a short, one- or two-sentence, description of what the

Development Team plans to achieve during the sprint. It is written
collaboratively by the Development Team and the Product Owner.

YOUR LOGO HERE
Definition of Done
When a Product Backlog item or an Increment is described as “Done”, everyone must

understand what “Done” means. Although this varies significantly per Scrum Team,
members must have a shared understanding of what it means for work to be
complete, to ensure transparency. This is the definition of “Done” for the Scrum Team
and is used to assess when work is complete on the product Increment.
The same definition guides the Development 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 product that adhere to the Scrum Team‟s
current definition of “Done.”
Development Teams deliver an Increment of the product every Sprint. This Increment
is useable, so a Product Owner may choose to immediately release it. If the definition
of "done" for an increment is part of the conventions, standards or guidelines of the
development organization, all Scrum Teams must follow it as a minimum.
If "done" for an increment is not a convention of the development organization, the
Development Team of the Scrum Team must define a definition of “done” appropriate
for the product. If there are multiple Scrum Teams working on the product release, the
Development Teams on all of the Scrum Teams must mutually define the definition of
“Done.”
Each Increment is additive to all prior Increments and, where appropriate, thoroughly
tested, ensuring that all Increments work together.
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to
include more stringent criteria for higher quality. Any one product or system should have
a definition of “Done” that is a standard for any work done on it.

YOUR LOGO HERE
‘Done’ in an IT environment
What is your definition of Done ?
What challenges do you face, how do you address them ?
What would need to change to get Done closer to a Released product? What release
cadence makes sense for your organization and customer base?

YOUR LOGO HERE
Sprint Planning
Planning approaches
Aim to get Development Teams to predictable, reliable delivery. The Development Team
more or less finish what they plan every Sprint. They are completing PBIs to DONE and their
Velocity is relatively stable and has a narrow range.
For Development Teams in a less For more experienced Development

predictable environment. Teams. If they are finishing what they
plan more or less every sprint, the
Development Teams missing their Sprint
Development Teams have the
Goals
experience to move to a lighter
Less experienced Development Teams planning model. They would use last
Development Teams that have a Sprints Velocity for the next Sprint and
number of incomplete Product Backlog do very little task estimating in Sprint
Items each Sprint Planning
Notes

YOUR LOGO HERE
Capacity Planning

YOUR LOGO HERE
Sprint Planning Meeting – What then How
Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality1 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.
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 Backlog2, and it provides
guidance to the Development Team on why it is building the Increment.
1
In a context where functionality does not accurately describe what is being developed, think of this more as
building changes into the product, whatever that product may be.
2
This typically refers to the subset of the product backlog selected for the Sprint rather than the backlog in its
entirety

YOUR LOGO HERE
4.3.2 Topic Two: 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 functionality3 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 system4 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.
The Sprint Backlog on a Task Board
3
In a context where functionality does not accurately describe what is being developed, think of this more as
building changes into the product, whatever that product may be.
4
Outside of an IT context the team will start by designing the product whatever that may be

YOUR LOGO HERE
Held Electronically with additional information indicators
Sprint Planning Reflection
Notes

YOUR LOGO HERE
Sprint Progress

YOUR LOGO HERE
Indicators of Visible Progress
Scrum relies on transparency. Decisions to optimize value and control risk are made
based on the perceived state of the artefacts. To the extent that transparency is
complete, these decisions have a sound basis. To the extent that the artefacts are
incompletely transparent, these decisions can be flawed, value may diminish and risk may
increase.
The Scrum Master must work with the Product Owner, Development Team, and other
involved parties to understand if the artefacts are completely transparent. There are
practices for coping with incomplete transparency; the Scrum Master must help everyone
apply the most appropriate practices in the absence of complete transparency. A Scrum
Master can detect incomplete transparency by inspecting the artefacts, sensing patterns,
listening closely to what is being said, and detecting differences between expected and
real results.
The Scrum Master‟s job is to work with the Scrum Team and the organization to increase
the transparency of the artefacts. This work usually involves learning, convincing, and
change. Transparency doesn‟t occur overnight but is a path.

YOUR LOGO HERE
Sprint Burndown Charts

Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be
summed. The Development Team tracks this total work remaining at least for every Daily
Scrum in order to project the likelihood of achieving the Sprint Goal. By tracking the
remaining work throughout the Sprint, the Development Team can manage itsprogress.
Burndown Charts
• Show net progress

• Raise questions; they don‟t answer them
• Facilitate early discussions
• Promote transparency (difficult to lie)
Trends

YOUR LOGO HERE
Notes

YOUR LOGO HERE
Initial Scrum Master Focus Areas

Artefacts
• Are the artefacts being used and kept up to date correctly?
• Is the Product Backlog prioritised and ordered?
• Is the Product Backlog and burn down charts being updated and valuable to the Scrum
Team
• Are the artefacts visible?
Roles
• Is the development team clear on their goal and focussed?
• Is the development team working effectively as a team?
• Are the Product Owner carrying out their responsibilities and are they showing
appropriate attributes
Quality
• Is Done being consistently expanded, are there frequent deployments
• Are tests being automated, is code being refactored?
Meetings
• Are the Scrum meetings valuable to the Scrum Team and carried out effectively
Collaborative
• Are you removing barriers to collaboration and effective communication
• Is the organization releasing joined up slices of functionality early and frequently?

YOUR LOGO HERE
Your Plan
Have you achieved your course learning objectives? If not, include those in your next
steps.
Your Next Steps …

YOUR LOGO HERE
Scrum Master Examination

At the end of the course, there is an exam.
• 50 simple, multiple choice questions

• 40 minutes
• Closed book
• Pass mark: 37 marks out of 50 (74%)
Multiple choice question styles

• Standard –The most common question style used
• Negative - A negative word is used in the question stem which is in bold and capitals to
emphasize the meaning
• Missing Word(s) -Candidates are required to identify the missing word or words from
the sentence presented
• Select (List) - Candidates must evaluate four statements and identify which three out of
the four are correct
• Select (Evaluate) - Candidates must evaluate two statements and determine whether
they are true or false
All exam questions

• Four answer options are provided
• Only one answer is correct
• There are no trick questions
• There is a sample paper for you to practice on

YOUR LOGO HERE
After Passing the Exam
• All candidates will be informed formally of their result

by APMG
• Successful candidates will receive an e-certificate and
digital badge
• Successful candidates will receive one year‟s free
membership of the Agile Business Consortium. You will
receive an email from APMG following your course with
details of how to register for your free membership.
Share your success on social media

Select an icon and personalise your post – thank your trainer and ATO
Claim and share your digital badge
• Update your network with your new skills

• Get the recognition you deserve
• Permanently update your CV
Digital badges are Open Standard and may be shared and verified online in a safe and secure way.
They contain detailed information on your qualification to help you gain the recognition you deserve.

YOUR LOGO HERE
Digital Badges for Candidates
Claim your digital badge

When viewing your exam results in the Candidate Portal, select the option to „Create
Badge‟ and register yourself.
Now, accept your pending badge

YOUR LOGO HERE
Share it!
Why do people share badges?

A study by LinkedIn found three reasons why employees share professional content:

YOUR LOGO HERE
Scrum Master Reading List
Agile Project Management and Scrum v2

by Andrew Craddock
Scrum Mastery by Geoff Watts
Coaching Agile Teams: A Companion for Scrum
Masters, Agile Coaches, and Project Managers in
Transition by Lyssa Atkins
Implementing Lean Software Development by Mary
& Tom Poppendieck
Agile Project Management with Scrum by Ken
Schwaber
Agile Software Development with Scrum by Ken
Schwaber and Mike Beedle
Agile Estimating and Planning by Mike Cohn
User Stories Applied for Agile Software Development
by Mike Cohn
Succeeding with Agile: Software Development using
Scrum by Mike Cohn
Essential Scrum: A Practical Guide to the Most
Popular Agile Process by Kenny Rubin
Agile Retrospectives by Esther Derby and Diana
Larsen
Game Storming by Dave Gray, Sunni Brown, James
Macanufo
Agile Testing: A Practical Guide for Testers and Agile
Teams by Lisa Crispin and Janet Gregory
The Leader’s Guide to Radical Management by
Stephen Denning
Large Scale Scrum: More with Less by Craig
Larman and Bas Vodde
Continuous Delivery by Jez Humble & David Farley

Agile Business Consortium Scrum Master Workbook v5.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Business Consortium Scrum Master Workbook v5.0

Uploaded by

Copyright:

Available Formats

Agile Business Consortium

Scrum Master Course

Copyright © 2019 Agile Business Consortium. All rights reserved

My Learning Objectives for this Course

Agile Business Consortium Scrum Master P a g e |2 © 2019 Agile Business Consortium

Scrum and Roles Overview

Agile Business Consortium Scrum Master P a g e |3 © 2019 Agile Business Consortium

Scrum is a framework within which people can address complex adaptive

Scrum is a framework that has been used to manage complex product

Agile Business Consortium Scrum Master P a g e |4 © 2019 Agile Business Consortium

Responsible for maximizing the value of the product resulting from

A servant-leader that does whatever it takes to make the Scrum

The professionals who do the work of delivering a potentially

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities

Agile Business Consortium Scrum Master P a g e |5 © 2019 Agile Business Consortium

Scrum Master Responsibilities

Agile Business Consortium Scrum Master P a g e |6 © 2019 Agile Business Consortium

Agile Business Consortium Scrum Master P a g e |7 © 2019 Agile Business Consortium

Self Organization Model

Based on: Glenda Eoyang: Conditions for Self-Organising in Human Systems

Agile Business Consortium Scrum Master P a g e |8 © 2019 Agile Business Consortium

 A “container” that sets the context for expected team behaviors

 Created by the whole Scrum Team

Agile Business Consortium Scrum Master P a g e |9 © 2019 Agile Business Consortium

Agile Business Consortium Scrum Master P a g e | 10 © 2019 Agile Business Consortium

Agile Business Consortium Scrum Master P a g e | 11 © 2019 Agile Business Consortium

The Agile Business Consortium are building on the

Individuals and interactions over processes and tools

That is, while we value the items on the right,

Agile Business Consortium Scrum Master P a g e | 12 © 2019 Agile Business Consortium

We follow these principles:

Agile Business Consortium Scrum Master P a g e | 13 © 2019 Agile Business Consortium

• Discuss the Agile Principles

Agile Business Consortium Scrum Master P a g e | 14 © 2019 Agile Business Consortium

• People personally COMMIT to achieving the goals of the Scrum team

Agile Business Consortium Scrum Master P a g e | 15 © 2019 Agile Business Consortium

Empirical Product Development

Agile Business Consortium Scrum Master P a g e | 16 © 2019 Agile Business Consortium

Story Mapping: Jeff Patton

Agile Business Consortium Scrum Master P a g e | 17 © 2019 Agile Business Consortium

Build up the solution piece by piece

Revisit previously worked-on process

For example… Building an online auction site:

Agile Business Consortium Scrum Master P a g e | 18 © 2019 Agile Business Consortium

Empirical Process Theory

Agile Business Consortium Scrum Master P a g e | 19 © 2019 Agile Business Consortium

Shifting the focus on solution management

What are the benefits of this approach?

Agile Business Consortium Scrum Master P a g e | 20 © 2019 Agile Business Consortium

Describe Scrum‟s relationship to the Agile Manifesto

Agile Business Consortium Scrum Master P a g e | 21 © 2019 Agile Business Consortium

Agile Business Consortium Scrum Master P a g e | 22 © 2019 Agile Business Consortium

Time Boxes for Scrum Events

Sprint Planning 4 hours 8 hours

Agile Business Consortium Scrum Master P a g e | 23 © 2019 Agile Business Consortium

The Sprint Planning Event

Agile Business Consortium Scrum Master P a g e | 24 © 2019 Agile Business Consortium

Sprint Planning Part 1 - What

What can be done this Sprint?

Agile Business Consortium Scrum Master P a g e | 25 © 2019 Agile Business Consortium

Sprint Planning Part 2 – How

Agile Business Consortium Scrum Master P a g e | 26 © 2019 Agile Business Consortium

The Daily Scrum

Making the daily Scrum effective