What is Scrum

• Scrum is Lightweight, Simple to understand, Difficult to master

• Scrum is founded on empirical process control theory, or empiricism.
3 Pillars Empirical process control: transparency, inspection, and adaptation.
• Scrum Values: commitment, courage, focus, openness and respect
• Framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.
• Each component within the framework serves a specific purpose and is essential to Scrum’s
success and usage.

Scrum Values
• Commitment
• Courage
• Focus
• Openness
• Respect

Scrum Theory
Significant aspects of the process must be visible to those responsible for the outcome.
(Transparency)
Scrum users must frequently inspect Scrum artefacts and progress toward a Sprint Goal.
(Inspection)
An adjustment must be made as soon as possible to minimize further deviation.
(Adaptation)

The Scrum Team:

Product Owner (PO)
Size = One
• Product Owner is the sole person responsible for managing the Product Backlog.
• Product Owner remains accountable for Backlog (Dev Team May do the work)
• Backlog Management:
o Clearly expressing backlog items/Stories
o Ordering the items based on Value (Achieve Goals & Mission)
o Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows
what the Scrum Team will work on next
o To change a Product Backlog item’s priority must address the Product Owner
o No one can force the Development Team to work from a different set of
requirements

1|Page
Dev Team (DT) - Testing, Architecture, Operations, BA etc.
Size = 3 - 9
• Do the work of delivering a potentially releasable Increment of “Done” product at the end of
each Sprint. A “Done” increment is required at the Sprint Review.
• Create the anticipated Increment by the end of the Sprint.
• Deliver an Increment of product functionality every Sprint. This Increment is useable, so a
Product Owner may choose to immediately release it.
• Only members of the Development Team create the Increment
• They are self-organizing
• cross-functional, with all the skills as a team necessary to create a product Increment
• Accountability of dev work belongs to the Development Team as a whole

Scrum Master (SM)

Size = 1 (Can be from Dev Team)

• Responsible for promoting and supporting Scrum
• Helping everyone understand Scrum theory, practices, rules, and values (Coaching)
• The Scrum Master is a servant-leader for the Scrum Team
• Help PO for Product Backlog to maximize Value prioritisation
• Find Techniques for Backlog Management
• Facilitate Scrum Events/Ceremonies
• Removing Impediments to the Dev Team’s Progress
• Leading and coaching the organization in its Scrum adoption
• Planning Scrum implementations within the organization
• Artefact Transparency and apply techniques and practices to achieve this.

Scrum Events
• Create regularity and minimize the need for meetings
• All events are time-boxed events
• Once sprint begins, its duration is fixed and cannot be shortened or lengthened
• Each event in Scrum is a formal opportunity to inspect and adapt.
• Designed to enable critical transparency and inspection

2|Page
The Sprint
• The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”,
useable, and potentially releasable product Increment is created.
• Each Sprint has a goal
• Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
Sprint Review, and the Sprint Retrospective.
• New Sprint starts immediately after the conclusion of the previous Sprint.
• No changes are made that will endanger Sprint Goal (Consult PO)
• Quality never decrease
• Scope can be clarified or re-negotiated with PO, for Dev Team
• Sprints also limit risk to one calendar month of cost.

Cancelling Sprint
• A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the
authority to cancel the Sprint.
• if the Sprint Goal becomes obsolete.
• When Cancelled: any completed and “Done” Product Backlog items are reviewed.
• All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog

Sprint Planning
• Time-boxed to a maximum of 8 hours for a 1-month Sprint
• Plan is Created by the collaborative work of the entire Scrum Team
• During Sprint Planning the Scrum Team also crafts a Sprint Goal.
• 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.
• Only the Dev Team can assess what it can accomplish over the upcoming Sprint.
• Dev Team decide how it will build this functionality into a “Done” product Increment,
what/when
• Output: The Product Backlog items selected for this Sprint plus the plan for delivering them
is called the Sprint Backlog.
• The Product Owner can help to clarify the selected Product Backlog items and make trade-
offs.
• Dev Team may renegotiate the selected Product Backlog items with the Product Owner.

Sprint Goal
• Guidance to the Dev Team on why it is building increment
• Created during Sprint Planning Meeting
• Provide some flexibility regarding the functionality implemented
• If work is different, Dev Team collaborate with PO to negotiate the scope of Sprint Backlog
3|Page
Daily Scrum/Daily Standup
• 15-minute time-boxed event for the Dev Team
• The same time and place, each day to reduce complexity.
• Key Inspect and Adapt meeting
• Highlight and promote quick decision-making,
• Inspecting the work since the last Daily Scrum and forecasting upcoming Sprint
• Dev Team often meet immediately after the Daily Scrum for detailed discussions, or to
adapt, or replan,

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?

Sprint Review
• 4 Hour meeting for 1-month Sprints.
• At the end of the Sprint to inspect the Increment and adapt the Product Backlog
• Showcase/Presentation of the product increment to get Feedback/collaboration
• 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.
• 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.

Sprint Retrospective
• 3 hour meeting for 1-month Sprints.
• After the Sprint Review and prior to the next Sprint Planning.
• For the Scrum Team to inspect itself and create a plan for improvements
• Formal opportunity to focus on inspection and adaptation.
• Scrum Team plans ways to increase product quality by improving work processes or adapting
the definition of “Done”,

What went well? (Process, People, Technology etc)

Start doing? Stop Doing? Continue doint?
Plan for Improvement (one item and add to Sprint Goal next)

Scrum Artefacts (provide Transparency and opportunity for Inspect &

Adapt)

4|Page
Product Backlog
• Product Owner is Responsible (include Content, availability and ordering)
• Ordered list of everything that is known. (Defects, bugs, new work, removed work etc)
• Single Source of requirements for any changes to the product & everything
• Is never complete. It evolves as product evolves.
• Is dynamic and Living as market/tech condition change/evolve.
• Exist for the life of the product
• lists all features, functions, requirements, enhancements, and fixes (if known for future too)
Have attributes of a description, order, estimate, and value.
• Often include test descriptions that will prove its completeness when “Done.”

Product Backlog Refinement (Grooming)

• No more than 10% of the capacity of the Development Team.

• The Dev Team is responsible for all estimates.
• Act of adding detail, estimates, and order to items in the Product Backlog.
• Ongoing process in which the Product Owner and the Development Team collaborate
• Items are reviewed and revised.
• The Scrum Team decides how and when refinement is done
• Higher ordered Product Backlog items are usually clearer and more detailed than lower
ordered ones.
• 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.
• The Product Owner may influence the Development Team by helping it understand and
select trade-offs

Sprint Backlog
• By Dev Team Only about what Product Backlog Items selected in Sprint + Plan, and what
functionality will be in next increment
• And work needed to deliver that functionality into “Done” increment.
• Visible work that Dev Team carry out to meet Sprint Goal.
Emerges during Sprint and Dev Team update/modify as work progress
• At Least One High priority process improvement identified in previous Retrospective
• Any New work agreed, Dev Team add in Sprint Backlog. If any elements unnecessary,
remove them
• Estimated Remaining work is updated as progress.

Product Increment
• Sum of all the Product Backlog items completed during a Sprint and the value of the
increments of all previous Sprints.

5|Page
 • New Increment must be “Done,” which means it must be in useable condition and meet the
Scrum Team’s definition of “Done.”
• The increment must be in useable condition regardless of whether the Product Owner
decides to release it.
• Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all
Increments work together.

Definition of “Done”
• Everyone must understand what “Done” means. All must have a shared understanding of
what it means for work to be complete
• Is used to assess when work is complete on the product Increment.
• The purpose of each Sprint is to deliver Increments of potentially releasable functionality
that adhere to the Scrum Team’s current definition of “Done.”
• It is expected that their definitions of “Done” will expand to include more stringent criteria
for higher quality. New definitions, as used, may uncover work to be done in previously
“Done” increments. Any one product or system should have a definition of “Done” that is a
standard for any work done on it.

The total work remaining to reach a goal can be summed. The Product Owner tracks this total work
remaining at least every Sprint Review.

The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess
progress toward completing projected work by the desired time for the goal Forecast progress, like
burn-downs, burn-ups, or cumulative flows.

https://www.scrum.org/resources/suggested-reading-professional-scrum-master

Understanding and Applying the Scrum Framework

• Empiricism
• Scrum Values
• Roles
• Events
• Artifacts
• Done
• Scaling

Developing People and Teams

• Self-Organizing Teams
• Facilitation
6|Page
 • Leadership Styles
• Coaching & Mentoring
• Teaching

Managing Products with Agility

• Forecasting & Release Planning

• Product Vision
• Product Value
• Product Backlog Management
• Business Strategy
• Stakeholders & Customers

Developing & Delivering Products Professionally

• Emergent Software Development

• Managing Technical Risk
• Continuous Quality
• Continuous Integration
• Continuous Delivery
• Optimizing Flow

Evolving the Agile Organization

• Organizational Design & Culture

• Portfolio Planning
• Evidence Based Management™

The Scrum Guide

The most obvious answer can be found in the Scrum Guide itself. It offers a clear
description of the services a Scrum Master provides to the Development Team,
Product Owner and the organization. Some examples of these services are
coaching the Development Team in self-organization and cross-functionality,
helping the Product Owner finding techniques for effective Product Backlog
management and supporting the organization in its Scrum adoption.
My Personal Description
Being a Scrum Master myself, I've tried to capture my role in a few sentences. It's
part of the "about me" page on my personal website. According to the Scrum
Guide, I also emphasize offering services to the Development Team, Product
Owner and organization (from the perspective of the Scrum Team).

7|Page
As a Scrum Master...
My main focus is creating successful teams with strong skills in self-
organization and cross-functionality and a drive for continuous
improvement. I support Product Owners in visualising progress, creating a
transparent Product Backlog and maximizing the value of the product. I help
organisations in making Scrum successful by supporting management in
changing processes, procedures, culture and behaviour. Due a strong focus on
the principles of Agile and the values of Scrum, I try to ensure the spirit of
Scrum is truly understood.

Characteristics of a Great Scrum Master

In the white paper 'Characteristics of a Great Scrum Team' I offer a detailed
description of the characteristics and skills of a great Product Owner, Scrum
Master and Development Team. Below I've shared some of the characteristics of
a great Scrum Master. These aren't all tangible tasks but will give you an idea
what to expect from a Scrum Master.
A great Scrum Master...

• Ensures the entire team supports the chosen Scrum process;

• Manages the impediments that exceed the self-organizing capabilities of
the team and it prevents them in achieving the Sprint Goal;
• Recognizes healthy team conflict and promotes constructive
disagreement;
• Is prepared to be disruptive enough to enforce a change within the
organization;
• Understands the power of a self-organization;
• Understands the value of a steady sprint rhythm and does everything to
create and maintain it;
• Knows how to truly listen and is comfortable with silence;
• Understands the strength of coaching and has learned some powerful
questions by heart;
• Teaches the Product Owner how to maximize ROI and meet objectives;
• Is also competent with XP, Kanban and Lean.

The Most Important Part

So far I've described the services a Scrum Master offers according to the Scrum
Guide, the personal description I use, and some characteristics of a great Scrum
Master. Hopefully this will already offer you some insights on what a Scrum
Master is doing during the day.

But... I probably haven't yet clarified the title of this blog post "A Day in the Life of
a Scrum Master". That's because I haven't mentioned the most important part of
the Scrum Master role...
8|Page
First of all: a Scrum Master should always prevent a fully booked schedule. A
smart Scrum Master has lot's of free space in his/her agenda. The more the
better.

As a daily preparation a Scrum Master could consider questions like:

• How is my Product Owner doing?

o Is the Product Backlog in shape?
o How is he/she managing the stakeholders?
o What about delivering business value and return-on-investment?
• How is the Development Team doing?
o Are they working together?
o Is there conflict in the team, do they resolve that?
o Is the team making decisions?
• How are our engineering practices doing?
o Is the team caring and improving them?
o How is the test automation?
o Is the team expanding their Definition of Done?
• How is my organization doing?
o Is there inter-team coordination?
o What organizational impediments are in the way?
o What about the HR practices?

Of course these are not the only questions to consider. These are just some
examples based on the LeSS training I've attended. Continuously refreshing the
questions to determine my daily schedule as a Scrum Master, has become sort of
a habit for me.
A Day in the Life of a Scrum Master
If you're still reading this article: great! I'm finally going to clarify the title!

A day in the life of a Scrum Master:

• Start the day with an open and curious mind (and in my case some good
coffee)
• A good first question to consider is "How can I improve the live of the
Scrum Team by facilitating creativity and empowerment?"
• Remember: your agenda is as good as empty! Except for the Daily
Scrum and maybe some other Scrum events
• You attend the Daily Scrum as an observer. You listen to what is and
isn't being said.
• You consider some of the questions I've mentioned earlier.
• Based on your observations you determine your next steps. This might
be coaching, consulting, teaching, facilitating, mentoring, managing,
9|Page
 problem solving, conflict navigating or... just sitting with the team,
listening and watching the team.
• Doing "nothing" is a perfect activity for a Scrum Master! The biggest
pitfall for a Scrum Master is being too busy and not noticing what is really
going on.

Evolution of the Product Owner

Ron Eringa

Ron Eringa website Ron Eringa Twitter Ron Eringa LinkedIn Ron Eringa
contact View profile

4.8 from 3 ratings

Product Owner
What is a good Product Owner and am I the right person to fill in this role?
If you have ever struggled with this question, you should probably keep reading.

The advantage of being a trainer and a consultant at the same time is that you get
the chance to meet a lot of Product Owners. I hear the stories of Product Owners
struggling with their daily challenges. Sometimes these stories are beautiful &
inspiring, but mostly they look like an episode of 'House of Cards' (meaning it's
ugly and full of politics and tough decision making).
Looking at all these stories you can see an evolutionary pattern appear,
describing how a Product Owner grows in his role.
The pattern

Many Scrum minded organisations are trying to create a good implementation of

the Product Owner. But where do you start? What is the right person to fill in the
role of the Product Owner? Does he come from marketing, sales or maybe from
the IT department? Or maybe it's that perfect project or product manager? All
these questions will popup, once you start implementing Scrum. The answer to
this question is not that simple. It is hidden in the evolution pattern, that describes
how many organizations have implemented the role of the Product Owner.
The pattern describes the required 'features' of a Product Owner. It's an
10 | P a g e
incremental pattern, where at each step in the evolution the expected benefits of
the role grows. It's like a Russian nesting doll that becomes more beautiful and
richer the more it grows.
Five levels
The evolution pattern contains 5 levels of Product Owners that I encountered.
These levels can be described by a graph that we use in the Professional Product
Owner training:

Each of the PO-versions in the graph is an upgrade of its predecessor:

The Scribe

As a first attempt of implementing the Product Owner role, organizations often

start with someone who has strong analytic skills. This is often a member of the
Development Team that was used to writing requirement specs or someone who
used to be the 'Business Analyst'. Since this person typically comes from the IT
department, it is an easy to take first step towards implementing Scrum and we
can get started with the creation of a Product Backlog.
However, a Scribe has limited benefits, since he often needs others (marketing,
sales, product/project managers, steering committees, etc) to answer difficult

11 | P a g e
questions. This delegated decision making often leads to a disruption of the Flow,
Bottlenecks, large piles of stocked work and a slow generation of Business Value.
The Proxy

In order to solve the communication problems of a Scribe, organizations update

the Product Owner role with a senior analyst that has strong communication skills.
This person is like an account manager that is still coming from the IT
department. The focus of a Proxy shifts from creating Product Backlog items
towards creating Product Increments.
The expected benefits of a Proxy are slightly better, since he is more connected
to the business than the Scribe. Although the delays, waiting time and hick-ups
will decrease, many of those remain.
The Business Representative

A problem that is often heard with the Proxy (and also the Scribe) is that the
business (often marketing & sales) is disconnected from the IT department. Once
organizations understand that they need to break down the inter-departmental
barriers, they send in someone from marketing/sales/product management to fill
in the Product Owner role. This upgrade to business representative is the next
step in the evolution. From this moment on the Scrum team consists of people
from all parts of the organization, and not only from the IT department.
The expected benefits increase again, since there is a broader collaboration. Now
there is direct availability of functional knowledge & stakeholder expectations. Yet,

12 | P a g e
the business representative still has limited autonomy, since
marketing\sales\product management department are still the real authorities.
The Sponsor

Once a Business Representative has felt the pain of continuously asking the
business departments to make decisions, he will probably fight to get some
mandate. Once the business departments dare to give control to and trust the
Business Representative, the next step in the evolution is made and the Business
Representative is upgraded to a Sponsor.
It works better if the person is not only from business, but also has the trust and
the mandate to take decisions (on the spot). A mandate is a signal that the role is
taken more seriously. The sponsor is often allowed to spend more time as a
Product Owner, leading to less hick-ups, context\task switching & largely
improved flow. The Development Team can focus more, and get things done.
The issues of a Sponsor mostly come down to a need for lobbying for budget. A
sponsor still needs to negotiate to free up money from the different business
departments. Maybe he can already decide on how to spend the money for his
own department, but there are still other departments that need to be convinced.
The Entrepreneur

The last step in the evolution of the Product Owner is to make him fully
responsible for functionality and budgets. This makes him a real Entrepreneur,
whose job is to create as much Business Value for his customers as possible.
He's like a mini-CEO, a real owner over the product.
The Entrepreneur is responsible for all aspects, like marketing, competition,
users, legal & finance within the scope of his product. His professional life is
13 | P a g e
dedicated to the well-being of the product.
Unfortunately, these kind of Product Owners are still a rare species, since
organizations are often not ready to delegate this kind of control.

If you would like to use the personas described in a workshop, you can download
them here.

The Sprint is one of the five Scrum events. In my Professional Scrum Courses,
this is the event that people often forget about because it is a container event, not
necessarily something you distinctly schedule on the calendar.

This container holds the space for all of the work to create the shippable
Increment of product, and it is limited to one month or less in duration (i.e. time-
box). This container starts with Sprint Planning and ends with the Sprint
Retrospective. Then the next Sprint immediately starts.

The Sprint can seem like a simple administrative term, and people sometimes
brush it off.
However, the Sprint holds so much power in Scrum.
This is why the Scrum Guide calls the Sprint the “heart of Scrum.” Let’s take a
look at 5 powerful things the Sprint provides teams and organizations.
#1 – Focus
The purpose of a Sprint is to create a potentially releasable product Increment
of value to the organization. It’s that simple.

What value is to be delivered is guided by the Sprint Goal, which does not change
during the Sprint. Because… well, focus.

If you’ve worked in product development for even a day, you probably understand
how chaotic it can feel. New ideas and new business needs are popping
up. New information about the market and customers is being discovered. And
of course, the complexity of the actual work a team is doing creates a continuous
flow of new learning and new challenges.

By having this single purpose every Sprint – to create a releasable Increment –

the team can bring their focus back to this. They can set aside the
distractions not related to this purpose. They can take the new information
they have uncovered and adapt their plan without losing focus.

This brings us to predictability.

14 | P a g e
#2 – Predictability
While a Scrum Team may not be able to guarantee the specific scope of the
Increment (i.e features/ functions), a team that is using Scrum well will be
predictable in delivering a “Done” Increment every Sprint.

Sprints have a consistent cadence. This consistent cadence helps a Scrum

Team understand what they are capable of delivering in a period of time. As a
Scrum Team understands this and continues to work together, they can better
forecast delivery expectations.

Disclaimer: Remember that the words “estimate” and “forecast” imply there is still
complexity and uncertainty, and these estimates and forecasts will not be
perfectly accurate. The Sprint helps us optimize predictability over time.

A Scrum Team can change the length of a Sprint, but they don’t change it
constantly. They do so intentionally as a part of their commitment to continuous
improvement in meeting the business needs. Then they learn and settle into a
new cadence.

And that brings us to #3. The Sprint provides control.

#3 – Control
A question I am often asked is,
How long should our Sprint be?”
My answer is always,
How frequently does your business need to change direction?”
Remember the Sprint Goal does not change during the Sprint. This provides the
stability a Development Team needs in order to get something meaningful done
(see #1 above). So the real driver of the length of a Sprint is how often the
business needs to inspect the Increment and adapt the direction based on
new information.

This gives the business control without creating an unstable situation for the
Development Team.

In addition, the Sprint time-box gives the business more transparency to and
control of cost and schedule. An organization can fund a number of Sprints
and see the value they are getting every Sprint. This helps make informed
decisions about whether or not to keep investing money and on what to invest
it. Ultimately, this is how you control risk in complex environments.

15 | P a g e
#4 – Freedom
A Sprint provides freedom. This may seem contradictory to point #3, but it is
not. And that is the beauty of a Sprint.

The Scrum Team has the focus of a Sprint Goal and a time-
box. These boundaries create the freedom for effective self-organization,
collaboration, and experimentation.

There are many ways risk shows up in product development. Are you building
the right thing? Are you building the thing right? What assumptions might be
wrong? What might change?

Teams have to learn by doing, inspecting and adapting along the way.

And businesses do too. The business gets the freedom to experiment as well.

Sometimes there will be failure. In fact, failure is a part of learning. The question
is how big of an impact that failure will have. A Sprint limits the impact of
failure to the time-box of the Sprint.

This freedom leads us to opportunity.

#5 – Opportunity
Scrum is a framework for opportunistic discovery. To quote Ken Schwaber, it
helps us “harness change for competitive advantage.” Ultimately, successful
Sprints enable the benefits of business agility.

Scrum is the art of the possible. It’s about being open to and ready for the
opportunities you discover throughout the journey.

16 | P a g e