Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
Principles behind the Agile Manifesto

We follow these principles: The sponsors, developers, and users

Our highest priority is to satisfy the should be able to maintain a constant
customer through early and continuous pace indefinitely.
delivery of valuable software.
Continuous attention to technical
Welcome changing requirements, even excellence and good design enhances
late in development. Agile processes agility.
harness change for the customer's
competitive advantage. Simplicity--the art of maximizing the
amount of work not done--is essential.
Deliver working software frequently,
from a couple of weeks to a couple of The best architectures, requirements,
months, with a preference to the and designs emerge from self-
shorter timescale. organizing teams.

Business people and developers must At regular intervals, the team reflects
work together daily throughout the on how to become more effective, then
project. tunes and adjusts
its behavior accordingly.
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.
Empiricism means working in a fact-based, experience-based, and evidence-based
manner. Scrum implements an empirical process where progress is based on
observations of reality, not fi ctitious plans. Scrum also places great emphasis on mind-
set and cultural shift to achieve business and organizational Agility.

• Transparency: This means presenting the facts as is. All people involved—the
customer, the CEO, individual contributors—are transparent in their day-to-day
dealings with others. They all trust each other, and they have the courage to
keep each other abreast of good news as well as bad news. Everyone strives
and collectively collaborates for the common organizational objective, and no one
has any hidden agenda.

• Inspection: Inspection in this context is not an inspection by an inspector or an

auditor but an inspection by every- one on the Scrum Team. The inspection can
be done for the product, processes, people aspects, practices, and continuous
improvements. For example, the team openly and transparently shows the
product at the end of each Sprint to the customer in order to gather valuable
feedback. If the customer changes the requirements during inspection, the team
does not complain but rather adapts by using this as an opportunity to
collaborate with the customer to clarify the requirements and test out the new
hypothesis.

• Adaptation: Adaptation in this context is about continuous improvement, the

ability to adapt based on the results of the inspection. Everyone in the
organization must ask this question regularly: Are we better off than yesterday?
For profi t-based organizations, the value is represented in terms of profi t. The
adaptation should eventually relay back to one of the reasons for adapting Agile
—for example, faster time to market, increased return on investment through
value- based delivery, reduced total cost of ownership through enhanced
software quality, and improved customer and employee satisfaction.
Scrum works not because it has three roles, five events, and three artifacts but because
it adheres to the underlying Agile principles of iterative, value-based incremental
delivery by frequently gathering customer feedback and embracing change. This results
in faster time to market, better delivery predictability, increased customer
responsiveness, ability to change direction by managing changing priorities, enhanced
software quality, and improved risk management.

This is one of the topics I covered in my book - "Scrum Insights For Practitioners: The
Scrum Guide Companion". Happy reading!
Maximize Scrum with the Scrum Values: Focus (Part 1/5)

This is the first in a five-part series about the Scrum values. These values are
focus, openness, courage, commitment, and respect. They are so important and so
often misunderstood that they were added to the Scrum Guide in July of 2016.

These five values are easy to remember, but it can be difficult to understand what they
mean, how to apply them, and how to recognize them in teams and individuals. Without
the Scrum values, we are just going through the motions and will not maximize the
benefits of Scrum and enable business agility.

Let's tackle focus in this post. When we are dealing with complexity and
unpredictability, focus is essential in order to get anything meaningful done.

Focus facilitates empiricism and collaborative teamwork.

• Instead of people working independently on separate Product Backlog Items,

Scrum Teams are often more effective when they collaborate on one or two
things. They get one thing done and then move on the next. This can reduce
potential waste from WIP (work in progress) and undone work at the end of a
Sprint. While Scrum doesn't tell you how to deliver, focus can lead a team to
discovering their best way to work to get things done sooner and minimize
waste.

• When there are multiple issues (I'm pretty sure they come in 3's), focus helps a
team determine what to tackle first, inspect their progress frequently, and try
new experiments as they work towards a solution.

• When there are competing priorities, focus helps a team decide what is the
most important thing right now.
 • When the future is uncertain, there is a tendency to want to keep analyzing.
Focus helps a team accept uncertainty, look at what they know today, and take
a small step. This approach works because we learn from doing and can change
direction based on what we learn.

• The Development Team's shared accountability to deliver the "Done" Increment

creates a focus on the overall outcome, not simply on what each individual can
accomplish.

• Having a product vision creates focus on where we are going, and that can
inform the team's decisions on a daily basis.
The Scrum framework includes elements that help promote focus.

• We focus on having a "Done"Increment at least by the end of every Sprint.

• The Scrum events and artifacts help create focus on inspecting progress and
new information, so we can adapt at frequent enough intervals.

• We focus on a Sprint Goal to guide the team in what to deliver.

• Each role has a distinct accountability which helps individuals know what to focus
on as their priority. That ultimately contributes to team outcomes.

• The Product Backlog is an ordered list, and that creates focus on what is most
important thing to do next.

• Time-boxed events create a sense of urgency and help us focus on the

purpose of the event.
These are just a few examples of how the Scrum value of focus lives within a Scrum
Team to help them maximize the benefits of Scrum. There are many more.
It's not just enough to tell a team, "these are the Scrum values," and give some
examples. Values are deeper than that. Teams need to continuously and
collaboratively refine what these values mean for them in order to truly maximize
Scrum.

Maximize Scrum with the Scrum Values: Openness (Part 2/5)

This is the second in a five-part series about the Scrum Values. These values
are focus, openness, courage, commitment, and respect. Without the Scrum values,
we are just going through the motions and will not maximize the benefits of Scrum.

These five values are easy to remember, but it can be difficult to understand what they
mean, how to apply them, and how to recognize them in teams and individuals. In this
post, we illuminate the value of openness. Openness is essential when we are dealing
with complexity and unpredictability.

Openness facilitates empiricism and collaborative teamwork.

• Being open about our work helps create transparency to our progress.
Without transparency, any attempts to inspect and adapt will be flawed.

• Openness enables team members to ask for help.

• Openness allows team members to offer help to each other.

 • Openness enables team members to share their perspectives, feel heard by their
peers, and be able to support team decisions.

• When our assumptions turn out to be invalid, openness helps us admit we were
wrong and change direction. This applies to a feature we thought would be
valuable. This also applies to how we chose to implement a feature in the
product.
The Scrum framework includes elements that help promote openness.

• Limiting a Sprint to 30 days or less promotes an openness to changing

direction base on new information.

• The Sprint Goal is fixed and provides guidance, but the plan for meeting the
Sprint Goal is open to change based on what the Development Team is
learning.

• A transparent Product Backlog demonstrates openness with our stakeholders

about what is planned for the product (and what is not planned) and what is likely
to be next.

• The Sprint Retrospective's focus on continuous improvement of our team's

interactions, processes, and tools invites an openness to feedback, reflection,
and changing how we work.

• The Sprint Review demonstrates openness to sharing progress with our

stakeholders, as well as openness to feedback and collaboration with them.
These are just a few examples of how the Scrum value of openness lives within a
Scrum Team to help them maximize the benefits of Scrum. There are many more.
Teams need to continuously and collaboratively refine what these values mean for
them in order to truly maximize Scrum.
Maximize Scrum with the Scrum Values: Courage (Part 3/5)

This is the third in a five-part series about the Scrum values. These values
are focus, openness, courage, commitment, and respect. It takes more than just
knowing what they are. Achieving the benefits of Scrum requires that people and teams
understand what they mean, how to apply them, and how to recognize them.

Courage is essential in solving complex problems and growing high performing teams.

Courage facilitates empiricism and collaborative teamwork.

• It takes courage to be transparent about progress under pressure to deliver

more faster.
• It takes courage to NOT show our stakeholders undone work.
• It takes courage to ask for help or admit we do not know how to do something.
• It takes courage to hold others accountable when they are not meeting
commitments to the team.
• We may discover we built something our customers don't want. It takes courage
to admit our assumptions were wrong and change direction.
• It takes courage to try to build something we've never built before, not knowing if
it will work or not.
• It takes courage to share a dissenting opinion with a team member and engage
in productive conflict.
• It takes courage to admit our mistakes. This could apply to our technical work,
our decisions, or how we conduct ourselves.

The Scrum framework includes elements that help promote courage.

• Every Scrum Event is an opportunity to inspect and adapt. This built-in

assumption that it's okay to change direction enables courage. We can
 change direction regarding what we are building. We can change direction
regarding how we are building it.
• The time-box of a Sprint limits the impact of failure to the length of a Sprint.
This gives us courage to try new things, to experiment, to learn.
• The three Scrum Roles and their distinct accountabilities promote courage. The
Product Owner is accountable for maximizing the value of the product, so she
can demonstrate courage by saying "no" to low value features. The
Development Team is accountable for delivering a quality product, so they can
demonstrate courage by saying "no" to cutting quality under pressure.
• We are transparent about our planned work through both the Sprint
Backlog and Product Backlog. We are transparent about our progress by
showing the completed Increment to our stakeholders. Transparency takes
courage, and transparency helps us build trust. The more trust we have, the
more courage we find. It's a virtuous cycle.
• The purpose of the Sprint Retrospective is to inspect ourselves as a Scrum Team
and identify actions for improvement. This enables courage to bring up issues
with how we are working together. This enables courage to try new things, to
want more.

These are just a few examples of how the Scrum value of courage lives within a Scrum
Team to help them maximize the benefits of Scrum. There are many more. Teams
need to continuously and collaboratively refine what these values mean for them in
order to truly maximize Scrum.
Maximize Scrum with the Scrum Values: Commitment (Part
4/5)

We are in the home stretch. This is the fourth in a five-part series about the Scrum
values. These values are focus, openness, courage, commitment, and respect.
Achieving the benefits of Scrum requires that people and teams understand what they
mean, how to apply them, and how to recognize them.

Commitment is essential in solving complex problems and growing high performing

teams. Commitment in Scrum is often misunderstood as a promise to deliver a set
scope by a set date. That was never the intention of the word commitment in the Scrum
Guide. I hope this post helps illuminate the value of commitment.

Commitment facilitates empiricism and collaborative teamwork.

• When we commit to the success of the team, not just caring about our
individual achievements, that creates an environment of trust, productive problem
solving, and high team standards.
• When we commit to doing Scrum fully, not just picking and choosing the easy
parts, we can fully experience the benefits of transparency, inspection, and
adaptation.
• Committing to continuous improvement makes it easier to change
direction based on new information or empirical data.
• Commitment is about dedication to doing our best. We cannot predict or
control all of the complexities in product development, but we can commit to
taking actions and adjusting our behaviors based on feedback and new
learnings.
• When we commit to delivering value, we feel a greater sense of shared
purpose that drives our motivation to collaborate.
The Scrum framework includes elements that help promote commitment.

• Every Scrum role has a distinct accountability, and this is a commitment.

◦ The Product Owner demonstrates commitment by making the best

decisions to optimize the value of the product, not simply trying to
please every stakeholder.

◦ The Development Team demonstrates commitment by creating an

Increment that meets their definition of "Done," not something that is
almost done.

◦ The Scrum Master demonstrates commitment by upholding the Scrum

Framework, which means we don't extend the Sprint or other time-boxes
under pressure to get to "Done." The Scrum Master demonstrates
commitment by removing impediments that the Scrum Team cannot
resolve themselves, rather than tolerating the status quo in the
organization.

• Delivering a "Done" increment by the end of the Sprint promotes a commitment

to quality and continuous improvement.

• The Product Backlog enables a commitment to transparency. Stakeholders

can see what is currently planned in the product and the current order.

• The Sprint Backlog enables a commitment to transparency of our progress.

The Development Team owns the Sprint Backlog, and it always reflect our
current progress based on what we have learned.
 • The Daily Scrum is an opportunity for the Development Team to
demonstrate commitment to each other. They collaboratively inspect their
progress and adapt their plan. They determine how they can best work together
to achieve the Sprint Goal.

• The Sprint Retrospective promotes a commitment to continuous

improvement as a team. We inspect our processes, tools, and interactions and
identify and commit to actionable improvements.

These are just a few examples of how the Scrum value of commitment lives within a
Scrum Team to help them maximize the benefits of Scrum. There are many more.
Teams need to continuously and collaboratively refine what these values mean for them
in order to truly maximize Scrum.

Maximize Scrum with the Scrum Values: Respect (Part 5 of 5)

This is it. The last in a five-part series about the Scrum Values. These values
are focus, openness, courage, commitment, and respect. Achieving the benefits of
Scrum requires that people and teams understand what these values mean, how to
apply them, and how to recognize them.

Respect is essential in solving complex problems and growing high performing teams.
This likely seems obvious, so I am going to share some of the more subtle examples
of the value of respect in Scrum.

Respect facilitates empiricism and collaborative teamwork.

• If we respect that people are naturally resourceful, creative, and capable of

collaboratively solving complex problems, we empower and enable self-
 organizing teams.

• By having respect for people's diverse backgrounds, experiences, and range

of skills, teams are able to effectively solve complex problems in creative ways.

• When we respect that people are motivated by autonomy, mastery, and

purpose, we create an environment that engages people and enables teams to
become greater than the sum of their parts.

• If we respect that people are doing their best given what they know at the time
and their current resources, we enable transparency. We make it okay to change
direction based on what we have learned.

• When we show respect for people and assume they have good intentions, we
can have difficult conversations that help us figure out ways to resolve conflict
and grow stronger as a team.

• When there is respect for all opinions and perspectives, we can ensure
everyone has the opportunity to be heard. When we feel we have been heard, it
is possible to fully support team decisions even if the decision was not our
preference.
The Scrum framework includes elements that help promote respect.

• The entire Scrum Team attends Sprint Planning, the Sprint Review, and the
Sprint Retrospective. This promotes respect for each role, the accountabilities,
and diverse perspectives.

• The Development Team is cross-functional, which means as a whole it has all

of the skills necessary to deliver a "Done" product Increment. This promotes
respect for everyone's experiences, skills, and ideas. This also promotes
 learning and growth.

• The Sprint Backlog is owned by the Development Team. Since they are the
ones doing the work, they decide how much they can do in a Sprint and how to
do the work. This demonstrates respect for their knowledge and skills, as well as
a respect for working at a sustainable pace.

• By only reviewing "Done" product in a Sprint Review, we bring transparency

to our true progress. This demonstrates respect for our stakeholders.

• A Product Owner seeks input from, collaborates with, and sets realistic
expectations for stakeholders. This is another demonstration of respect for
stakeholders.

• The Scrum Master's focus is on the health of the Scrum Team and the
effective use of Scrum. Having a role that focuses on teaching, facilitating, and
coaching demonstrates a respect for people and teams and their capacity for
growth.

• Scrum's focus on delivering value shows respect to our organization by not

spending money on low value features or things that may never be used.

• Having a potentially releasable Increment by the end of the Sprint shows

respect to our organization by not forcing more investment to realize value. It
gives the organization the flexibility to make investment decisions.
These are just a few examples of how the Scrum value of respect lives within a Scrum
Team to help them maximize the benefits of Scrum. There are many more. Teams
need to continuously and collaboratively refine what these values mean for them in
order to truly maximize Scrum.

I hope you have gained some insights from this five-post series on the Scrum Values.
Visualizing Scrum Values

Working as a Scrum Master I asked myself...

"How do I know if my team are demonstrating the Scrum Values? What can I use to

show their current state?"

Remembering an exercise I did some years ago whist at my local Agile group - Agile
Yorkshire, I thought I could use a "Spider Web" to visualise the state. ( SO a big thank
you to Agile Yorkshire and Royd Brayshay)

The exercise I used is to rate yourself of against a list of questions, giving yourself 1
point for each question you agreed with and then mark result on a scale. Once
completed you should end up with something like this:

What Questions Did I Use?

Courage

1. I work on the next highest priority Product Backlog Item (I do not cherry pick the
work I pick up in the Sprint)
2. If I see something that is wrong with what I'm being asked to do, I will say so.
3. I will question & reproach my team members if I feel that they are doing
something wrong.
4. Regardless of the person talking, I will correct them if I believe that they are
incorrect.
5. I will stand firm if I believe I am right, even if I'm in the minority within the group.

Commitment

1. I always know what the sprint goal is and how my work supports it.
2. I do everything I can to ensure we achieve the goals of the sprint.
3. In my current team, I have never thought of taking a sick day to avoid going into
work.
4. I always arrive on time for the events, my colleagues never have to wait for me to
start the event.
5. I know what it means to say that an item is done, i.e. I know the criteria that
meets our Definition of Done.

Focus

1. Whilst working on a story I do not get distracted.

2. If I am not enjoying the work in a story I still give it the attention it needs.
3. When enjoying working on a story I will not over work a story just to prolong it.
4. I do not procrastinate when working on a story.
5. As soon as the story is ready to move into a new state, I will tell my colleagues
and either hand it over or ensure that they know it is ready to pick up.

Openness
 1. I do not shy away from telling difficult news to team members and stakeholders
2. I do not hide away difficult issues in the hope that they will sort themselves out.
3. If something / someone is annoying me I will address it / tell them.
4. My colleagues can judge what state of mind I'm in, I can share my feelings with
my them.
5. I always say the true state of an item, and do not over/under play it.

Respect

1. I listen with equal intensity regardless of who is talking.

2. When listening to people I never talk over them.
3. I value everyone's opinion equally.
4. I am never concerned who works on what item in the backlog.
5. I feel that my opinion is respected and that I have an equal say in the team.
So, what was the result?
Our Next Steps

• To support & encourage one of our colleagues to focus on Respect.

◦ How? We're working on that one but we know it is an issue.
The whole processed enabled the team to talk more freely with each other. We
discussed the outliers and generally felt positive that we were open with each other.

My role as a Scrum Master was to look at the areas where people recorded low against
some key areas, (Respect, Courage and Openness) then encourage improvements in
these areas?
Scrum Values

Scrum Values came into the Scrum Guide in June 2016 with the aim of helping teams
support the 3 pillars of Empiricism (Inspection, Adaption and Transparency)
Roles In Scrum

I am enjoying the Vikings series with my wife, and it inspired a metaphor I have been
using when discussing Scrum and Agile Roles within the Scrum team. The roles in
Scrum are like the roles on long ship, and the purpose was either trade or raiding. The
crew of the ship work together to get to their destination and back. The key purpose of
Scrum is to build and deliver a potentially releasable increment every Sprint. The Scrum
Team works together to ensure that what they build in each and every Sprint is of the
highest possible value to the organisation or purpose that they serve.

The roles in Scrum using a long ship metaphor

Scrum has three roles, each with a different focus and accountability:

Product Owner (Green figure)

The "What". With a focus on Value, time to market, return on investment and Total Cost
of Ownership.

Development Team (red figures)

The "How". Focus on building something that is Done – that the increment is useable
and potentially releaseable

Scrum Master (blue figure)

Ensure that the Framework is understood and is used correctly for the business and the
team. Helping everyone understand how to use the framework to derive maximum value
and respond to the needs of the Market. They will also remove impediments that are
disrupting the Scrum Team's ability to achieve their common goal.

There is a supporting interlock between the three roles, with each role creating the
environment and understanding for the other roles to perform to their potential.

The Viking Ship Metaphor

One of the defining characteristics of the Viking culture is that of free will (for the free
people, unfortunately not for the slaves). The leader would provide a direction, however
the position itself would not automatically grant obedience. However once at sea, the
ship had a captain. Before setting to sea, the Captain would need to find a crew that
agrees with the intent of the journey (where to raid, trade or explore).
The Captain

Would choose the direction and navigate the ship. They would use their experience and
understanding of the conditions to steer the ship towards their intended direction.
Storms were to be expected, and there was a need for constant adjustments as in any
sailing.

The captain has the authority to steer the ship, and the duty of care to the rest of the
crew to find the best destination for them.

In Scrum - this is the Product Owner. The Product Backlog is the steering oar.

The Crew

When needed, the crew man the oars and row the ship, or manage the sail. They are
the ones responsible for keeping the ship moving to and from the destination.

In Scrum - this is the Development Team. They use the tools and environment available
to them to deliver a steadily growing increment of “Done” product.

The Bosun

Perhaps this is not historically accurate - but it helps in the metaphor!

There is someone who ensures the right things happen on the ship. Help everyone
know what their role is, get the ship rigged for the weather, when to ship oars and bang
the drum to row in time, etc.

In Scrum - this is the Scrum Master.

Visualising this:

Without a Development Team, there is no progress.

Without a Product Owner, the journey lacks direction and focus

Without a Scrum Master, the hidden dangers can halt the journey

As a full team, the destination is arrived at through focussed effort.

Mixing the roles

A recurring question is can a person occupy multiple roles?

Using the Ship metaphor, we can discuss the potential impact of being in multiple roles.
There is a probability that the person will focus on what they get the most satisfaction
from, leaning towards the activities that they like the most. Will they go to where they
are most needed? How will people know what role they are performing? Sometimes it is
more obvious where their efforts should be directed. It is likely that this will disrupt the
smooth running of the team. Remember that a functioning and performing team has a
dynamic that is characterised by the interactions between the members. There is no
fixed rule on this, as each situation is unique. The common effect is that neither role is
served effectively, or one of the roles is not serviced at all.

Product Owner and a Development Team member

Do they want to steer or row?

There is probably going to be times when the ship is not steered as they are rowing, or
the ship will go more slowly as they are steering not rowing.

Scrum Master and a Development Team member

Do they want to bang the drum or row?

There is probably going to be times when oars clash as they are not banging the drum,
or the ship loses momentum as they are drumming not rowing. It might just happen that
the ship moves fastest when they are banging the drum. When there is a new team
member, who will help them understand how to work the ship?

Product Owner and Scrum Master

Do they want to drum or steer? The conflict of interest between the two roles affects the
team and the product. The natural tension between product and framework is upset.

Serving many teams

I have worked with far too many organisations that encourage one person to serve
multiple teams in all roles. When you time share across teams it is challenging to be fair
to all the teams equitably. Typically, it is the team that is making the most noise that gets
the attention - that may not be the team with the greatest need. This is particularly
noticeable when an organisation starts to scale their product development.

In the longship metaphor, they spend most of their time swimming between ships – or
the ships have to slow down so that they can climb from one ship to another

When the storm hits...

In sailing when the storm hits, you need all hands on deck. You need to keep steering
the ship into the waves, or risk capsizing. If a big enough wave hits from the side, you
sink. Every member of the crew needs to perform their role effectively in order to keep
the ship afloat.

If we keep with the metaphor, the storm is the unexpected events that occur in product
delivery. When the unexpected happens, without having the people committed and
focussed to perform their roles then the unexpected may capsize the product - ending it
or pushing it off course.

Where the metaphor breaks down…

The Product Owner needs to trust the team within a Sprint and let them focus on
achieving the Sprint Goal – this is unlikely in a long ship.

The Development Team have the freedom to adapt the architecture and shape of the
Product to ensure that the product is releasable – this is not addressed in this metaphor!
During the Sprint the Product Owner should allow the Development team to self
organise in the way they deliver the Sprint Goal.

The Scrum Master adopts a Servant Leadership style, using an “Ask don’t tell” stance.
No Whip, no orders.

How are you sailing?

A special thank you to @N__Hutchinson who created the images for this blog!
I am enjoying the Vikings series with my wife, and it inspired a metaphor I have been
using when discussing Scrum and Agile Roles within the Scrum team. The roles in
Scrum are like the roles on long ship, and the purpose was either trade or raiding. The
crew of the ship work together to get to their destination and back. The key purpose of
Scrum is to build and deliver a potentially releasable increment every Sprint. The Scrum
Team works together to ensure that what they build in each and every Sprint is of the
highest possible value to the organisation or purpose that they serve.

The roles in Scrum using a long ship metaphor

Scrum has three roles, each with a different focus and accountability:

Product Owner (Green figure)

The "What". With a focus on Value, time to market, return on investment and Total Cost
of Ownership.

Development Team (red figures)

The "How". Focus on building something that is Done – that the increment is useable
and potentially releaseable

Scrum Master (blue figure)

Ensure that the Framework is understood and is used correctly for the business and the
team. Helping everyone understand how to use the framework to derive maximum value
and respond to the needs of the Market. They will also remove impediments that are
disrupting the Scrum Team's ability to achieve their common goal.

There is a supporting interlock between the three roles, with each role creating the
environment and understanding for the other roles to perform to their potential.

The Viking Ship Metaphor

One of the defining characteristics of the Viking culture is that of free will (for the free
people, unfortunately not for the slaves). The leader would provide a direction, however
the position itself would not automatically grant obedience. However once at sea, the
ship had a captain. Before setting to sea, the Captain would need to find a crew that
agrees with the intent of the journey (where to raid, trade or explore).

The Captain

Would choose the direction and navigate the ship. They would use their experience and
understanding of the conditions to steer the ship towards their intended direction.
Storms were to be expected, and there was a need for constant adjustments as in any
sailing.

The captain has the authority to steer the ship, and the duty of care to the rest of the
crew to find the best destination for them.

In Scrum - this is the Product Owner. The Product Backlog is the steering oar.
The Crew

When needed, the crew man the oars and row the ship, or manage the sail. They are
the ones responsible for keeping the ship moving to and from the destination.

In Scrum - this is the Development Team. They use the tools and environment available
to them to deliver a steadily growing increment of “Done” product.
The Bosun

Perhaps this is not historically accurate - but it helps in the metaphor!

There is someone who ensures the right things happen on the ship. Help everyone
know what their role is, get the ship rigged for the weather, when to ship oars and bang
the drum to row in time, etc.

In Scrum - this is the Scrum Master.

Visualising this:

• Without a Development Team, there is no progress.

• Without a Product Owner, the journey lacks direction and focus
• Without a Scrum Master, the hidden dangers can halt the journey
• As a full team, the destination is arrived at through focussed effort.

Mixing the roles

A recurring question is can a person occupy multiple roles?

Using the Ship metaphor, we can discuss the potential impact of being in multiple roles.
There is a probability that the person will focus on what they get the most satisfaction
from, leaning towards the activities that they like the most. Will they go to where they
are most needed? How will people know what role they are performing? Sometimes it is
more obvious where their efforts should be directed. It is likely that this will disrupt the
smooth running of the team. Remember that a functioning and performing team has a
dynamic that is characterised by the interactions between the members. There is no
fixed rule on this, as each situation is unique. The common effect is that neither role is
served effectively, or one of the roles is not serviced at all.

Product Owner and a Development Team member

Do they want to steer or row?

There is probably going to be times when the ship is not steered as they are rowing, or
the ship will go more slowly as they are steering not rowing.

Scrum Master and a Development Team member

Do they want to bang the drum or row?

There is probably going to be times when oars clash as they are not banging the drum,
or the ship loses momentum as they are drumming not rowing. It might just happen that
the ship moves fastest when they are banging the drum. When there is a new team
member, who will help them understand how to work the ship?

Product Owner and Scrum Master

Do they want to drum or steer? The conflict of interest between the two roles affects the
team and the product. The natural tension between product and framework is upset.

Serving many teams

I have worked with far too many organisations that encourage one person to serve
multiple teams in all roles. When you time share across teams it is challenging to be fair
to all the teams equitably. Typically, it is the team that is making the most noise that gets
the attention - that may not be the team with the greatest need. This is particularly
noticeable when an organisation starts to scale their product development.

In the longship metaphor, they spend most of their time swimming between ships – or
the ships have to slow down so that they can climb from one ship to another
When the storm hits...

In sailing when the storm hits, you need all hands on deck. You need to keep steering
the ship into the waves, or risk capsizing. If a big enough wave hits from the side, you
sink. Every member of the crew needs to perform their role effectively in order to keep
the ship afloat.

If we keep with the metaphor, the storm is the unexpected events that occur in product
delivery. When the unexpected happens, without having the people committed and
focussed to perform their roles then the unexpected may capsize the product - ending it
or pushing it off course.

Where the metaphor breaks down…

The Product Owner needs to trust the team within a Sprint and let them focus on
achieving the Sprint Goal – this is unlikely in a long ship.

The Development Team have the freedom to adapt the architecture and shape of the
Product to ensure that the product is releasable – this is not addressed in this metaphor!
During the Sprint the Product Owner should allow the Development team to self
organise in the way they deliver the Sprint Goal.

The Scrum Master adopts a Servant Leadership style, using an “Ask don’t tell” stance.
No Whip, no orders.

How are you sailing?

A Day in the Life of a Scrum Master

In a couple of short blog posts I’ll share the most common questions I get asked during
the Scrum.org Professional Scrum Master courses. I’ll focus on the Scrum Master role
and will provide an answer based on my personal experience as a Scrum Master. This
for sure isn’t the ultimate answer, it’s how I’ve fulfilled or experienced the situation
myself. I would love to learn from your experiences as well!

As part of this series I've already shared my view on the questions:

• “Can you be a part-time Scrum Master?“

• "Can you rotate the Scrum Master role?"
This blog post will be about the question:

What is a Scrum Master actually doing during the day?

Participants of my training that are completely new to Scrum often wonder what a
Scrum Master is actually doing during the day. The answer is something they discover
themselves during the training. However, it's not only a common question during
courses; also lot's of organizations I coach find the Scrum Master role difficult to grasp.

In this blog post I'll use different sources to answer the question:

• The description the Scrum Guide offers

• My personal description of a Scrum Master
• My white paper with the characteristics and skills of a "great Scrum Master"
• Questions a Scrum Master should consider every day
In the end I am going to clarify the title, and describe a day in the life of a Scrum Master.

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

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

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

Closing
In this blog post I've shared my view on the question "What is a Scrum Master actually
doing during the day?" I've used different sources and perspectives to answer this
question and in the end finally clarified the title and described a day in the life of a
Scrum Master.

If you are a Scrum Master as well, does this blog post make any sense to you? How
would you describe a day in the life of a Scrum Master? Of course I'm also curious to
the opinions of people not fulfilling this role.

Have a great day!

Evolution of the Scrum Master

In my last post I explained the pattern of an evoluting Product Owner. This blog is about
the evolution pattern of a Scrum Master.
Do you want to know more about what it takes to be a good Scrum Master? Would you
like to know how to grow in your role? Then you should propably keep reading.

Sucessful Scrum

In the last 10 years I have helped a number of organizations to implement Scrum.

For a lot of these organizations the Scrum implementation either takes a long time or
they never reach the real benefits of Scrum (happy stakeholders & maximum valued
products with high quality).
There is a close relation between the speed & sucess of the Scrum implementation and
the maturity of the Scrum Master role.

The pattern

So who is the perfect person for this role? Is it a (project) manager, a team leader or
maybe one of the development team members? Should he have technical skills or is he
more a people manager?
The answer to these questions are, also not simple. These answers are hidden in the
way many of these organizations have implemented the Scrum Master role. Another
pattern appears, that describes the evolution of the Scrum Master:
The more mature the Scrum Master becomes, the higher the expected benefits. Each of
the versions in the graph is an upgrade of its predecessor and incorporates all qualities
of the previous version:

The Clerk

As a first attempt of implementing the Scrum Master role, organizations often start with
one of the members of the development team (maybe he used to be the 'team leader').
Since he has proven to be good in organizing stuff, we think that this guy can easily pick
up some extra tasks ('how hard can it be to be a Scrum Master, right?'). While his main
responsibility is operational work on the Sprint Backlog, beeing a Scrum Master is
something he does in spare time.
On a day to day basis the Clerk typically removes a lot of administrative duties from the
Development Team (like updating the Sprint Backlog, burndown graphs, preparing the
Sprint Planning, etc).

A Clerk has limited benefits, since he is mostly focussed on himself & the inferior values
of the Agile manifesto (tools, processes, documentation, etc).

The Puppet Master

The Puppet Master is aware on the values in the manifesto (working software,
collaboration, interaction & embracing change). He understands how the mechanisms in
Scrum can help him reach these values.

He tries to pull different strings to make team members move into the right direction:
everyone in the team needs to follow the Scrum rules by the book. This often results in
a very mechanical Scrum implementation, where people do all the events, roles &
artifacts in Scrum, but not really live them.

Since he still supports the team in doing technical work, a Puppet Master often does not
have the time to focus on anything but his own Development Team.

The Organizer
Compared to the Clerk & the Puppet Master, the Organizer has managed to make his
team aware of the Scrum Values (Commitment, Focus, Openness, Respect & Courage).
He has realized that by doing all the complex technical work himself, he actually
prevents his team to learn (there is no need for other heroes when you already have
Superman).

So instead of beeing Superman, he steps aside. He facilitates that the team can do it
themselves ('We don't need strings to make the puppets move!'). As a result he can
focus on teaching people about Scrum.

He makes sure they actually live the values.

The Organizer is focussed on making sure that all Scrum events have an optimal result.
He also has made time to provide data, so people can start acting on facts instead of
gut feeling.
Although the Organizer himself acts with the Scrum Values in mind, his team is still
learning. The team still needs his full attention.

The Coach
A Development team that works with a Coach is able to run Scrum themselves.
Sometimes still a little mechanical, but most of the times they really start living the
values. As a result he has enough room to also focus on the Product Owner and the
environment around the team (stakeholders, management, etc).

The Coach is able to impact others with his knowledge, while the Organizer only used
this knowledge himself. He doesn't only listen to his own voice. He is able to
empathically listen to others. He is able to make people connect to their passion. He
also helps them take action towards this passion. He helps people to find new
viewpoints & evolve.

Besides using data to take decisions, the Coach starts to listen to his intuition.

The focus of a Coach gradually shifts from the team towards the rest of the
organization. However, he still struggles to find solid ground with management & other
parts of the organization (marketing, sales, operations, you name it...).

The Advisor
The Advisor has acted as a Coach for more teams in the past. He succeeded in
creating\enabling empowered Scrum teams. As a result of that his focus has now
shifted towards the organisation. He fixes impediments on the organizational level. He
uses data, but he mostly acts on intuition.

The Advisor helps new Scrum Masters with a lower evolution level to grow. He is often
asked by managers to help them fix difficult issues.

In an organization with complex, large products, the Advisor is typically the Scrum
Master for a number of scaled Scrum teams (in a Nexus he might also be the Scrum
Master for the integration team).

While he learns a lot about the organizational dynamics the Advisor still struggles in
making organizations more responsive as a whole.

The Expert
The Expert Scrum Master is highly competent & committed. He uses his unconscious
competence and intuition to advise\coach others on making decisions. The Expert has a
connection with all parts of the organization. He gives advice to managers, HR
professionals. He leads the organization towards more Agility. The Expert helps creating
new rules & standards.

Some of the Experts are still part of a Scrum team, because they love the atmosphere
around there. These teams are often high performing, skilled and an example for the
other teams in the organization.

Experts in an Agile organization often call themselves 'Agile coach'. They show up at
events and are often respectable members in a community of Experts.

Unfortunately, many organizations do not recognize these Experts or don't understand

how to keep them motivated. If they eventually leave, it will be a hard job to fill the
vacuum they leave behind.

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

Want to know about the evolution of the developer, development team and the Agile
manager? Keep reading the upcoming blog posts, there is more to come!!
5 Powerful Things About the Sprint

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.

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

#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.
Getting to Done: Creating Good Sprint Goals

In a previous post describing challenges to creating a done Increment, I identified a lack

of clear Sprint Goals as one of those challenges. According to the Scrum Guide, the
Sprint Goal is an objective to be met by the Sprint through the implementation of part of
the Product Backlog.

The Sprint Goal provides guidance to why we are building the Increment.

If we have a Sprint Backlog, essentially the plan for the Sprint, why do we need a Sprint
Goal?

Remember that software development is complex, and we cannot plan perfectly for
the unknown. When we create the Sprint Backlog, there is an expectation that work
will emerge during the Sprint. Scope may need to be re-negotiated. The Sprint Goal
helps provide focus on an objective we want to achieve and allows the flexibility to
negotiate the work to achieve that objective.

Creating a clear Sprint Goal can be challenging for Scrum Teams, and this often comes
up when I teach Professional Scrum courses.

4 Challenges With Sprint Goals (and some tips for resolving them)

1 - The Sprint Goal is too big.

When we have compound Sprint Goals (e.g. achieve X and Y and Z), we are splitting
focus and not allowing much flexibility. Here are a few reasons we end up in this
situation and suggestions for how to think differently.
 • We are working on multiple unrelated projects or initiatives. When we are
ordering the Product Backlog and doing Sprint Planning, consider both cohesion
of the work and the top priority initiative. When we cram too much into a Sprint,
we are setting ourselves up for failure. We end up with waste due to context
switching and little room for the work to emerge as we learn. If it feels impossible
to choose one, perhaps our Sprints are too long and do not provide the business
the opportunity to change focus and direction frequently enough.

• We try to encompass every Product Backlog Item (PBI). When I teach Scrum
courses, I often hear that teams consider their Sprint Goal to be "complete every
PBI." This is the equivalent of not having a Sprint Goal at all. This feels a bit
lazy. Yes, coming up with good Sprint Goals is hard. Take the time to do it.

• We think the team may not work as hard if the challenge isn't big
enough. This sentiment reminds me a command-and-control mindset. If self-
organizing, empowered teams are to be effective, we must believe that people
are committed to doing their best. If the Sprint Goal is met before the end of the
Sprint, professionals will fi gure out what else they can do to contribute in
meaningful ways. This could mean delivering more functionality. This could
mean working on continuous improvement items. Trust them to fi gure it out.

2 - The Sprint Goal is vague.

When we get to the end of a Sprint, is the entire team in agreement on whether or not
the Sprint Goal has been achieved? If not, the Sprint Goal may be too vague. Here are
a few tips for creating more clear Sprint Goals.

• During Sprint Planning, ask "how will we know if we have achieved the
Sprint Goal?" If we have different answers or puzzled looks from the Product
 Owner or any Development Team members, then we need further discussion and
refi nement of the Sprint Goal.

• Make the Sprint Goal measurable. This helps reduce subjectivity, or opinion.

• During Sprint Planning, use a consensus technique to confirm everyone's

understanding and commitment to the Sprint Goal. This is also a way to
help encourage team ownership.

Here are some examples of unclear Sprint Goals and modifications to make them
clearer.

Unclear Sprint Goal Clearer Sprint Goal

Streamline purchasing process to
Enhance shopping cart functionality. enable an increase in conversion
rates.
Improve performance. Increase page load time by X%.
Enable new market segment to
On-board new market segment.
purchase Service Y.

3 - The team doesn't pay attention to the Sprint Goal during the Sprint.

Remember we have to actually pay attention to it to help provide focus.

• Make it visible. Write the Sprint Goal on or near the Scrum Board. Make it
large. Use a color or border that stands out.

• Teach the team to talk about progress towards the Sprint Goal in the Daily
Scrum. Development Team members often give updates about the Product
 Backlog Items they are working on, and the Sprint Goal is never discussed.
Make it part of the Daily Scrum.

• Make the Sprint Goal a team measure and keep it visible in the team
space. Similar to how a team may track their velocity or automated test
coverage over time, a team can also track Sprint Goal achievement over time.
Keeping this information visible helps the team think about it. Historical data and
trends can be used for discussion in the Sprint Retrospective. A word of caution:
achieving a Sprint Goal is pass/ fail. There is no such thing as 85% achieved.

4 - The Sprint Goal doesn't feel meaningful.

A Sprint Goal is supposed to provide purpose. It helps the team know why they are
building the Increment. People want to do meaningful work. People want to do work
that has an impact. This is a driver for intrinsic motivation. Lets think about ways to
make Sprint Goals more meaningful to the people who are building the product.

• Make it business or user focused when possible. What will a user be able to
do when we implement this feature? What will a business area be able to
achieve when we implement an enhancement?

• Make it focused on testing business assumptions and getting feedback.

Many times we do not know what users actually need or are willing to do
(because even users don't know). A Product Owner needs early feedback to test
assumptions regarding value to users.

• Make it focused on reducing risk. Proving out a technology or design is an

important part of reducing risk. If we learn that a technology is not going to meet
our needs for performance, security, or scalability, we can change direction. The
earlier we change direction, the cheaper the cost of the change.
In summary, a good Sprint Goal can help a team focus and have the flexibility to create
a Done Increment by the end of a Sprint. A good Sprint Goal helps a team understand
the purpose and impact of the work they are doing, which is a driver for intrinsic
motivation. Roman Pichler provides a helpful template for creating effective Sprint
Goals.
Myth: The Scrum Master must be present during the Daily
Scrum

Scrum is intended as a simple, yet sufficient framework for complex product delivery.
Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology.
Instead, Scrum provides the minimal boundaries within which teams can self-organize
to solve a complex problem using an empirical approach. This simplicity is its greatest
strength, but also the source of many misinterpretations and myths surrounding Scrum.
In this series of posts we - your ‘mythbusters’ Christiaan Verwijs & Barry Overeem - will
address the most common myths and misunderstandings. PS: the visuals are by Thea
Schukken.

Myth: The Scrum Master must be present during the Daily Scrum

The myth is that a Scrum Master should always be present during the Daily Scrum. In
some teams, the Scrum Master is expected to facilitate the Daily Scrum, while other
teams feel that the Scrum Master should be present to pick up impediments that he or
she needs to solve. Either way; presence is required.

What does the Scrum Guide say?

According to the Scrum Guide, the Daily Scrum is owned by the Development Team.
Scrum is built on the observation that product development is a complex endeavour.
This complexity manifests in a high degree of unpredictability. Even within the scope of
a single Sprint, things will probably not go as expected. A critical member of the team
becomes sick during the Sprint. A high-priority bug is discovered that needs to be fixed
right away. Or a new idea emerges that better addresses the Sprint Goal. Frequent
communication within the Development Team is paramount to deal with these changes
as they arise.
The Daily Scrum is one of the boundaries of Scrum, and provides the Development
Team with at least one daily opportunity to synchronize work and plan for the day
ahead. How will the team work together until the next Daily Scrum to meet the Sprint
Goal? The output of the Daily Scrum consists of a daily plan and (potentially)
adjustments to the Sprint Backlog that are needed to reach the Sprint Goal. Although
the Scrum Master can be present to help facilitate the Daily Scrum, this is not
required. The Scrum Master ensures that a Daily Scrum takes place, but the
Development Team is responsible for conducting the meeting. Outside of the
Development Team and potentially the Scrum Master, no other people participate. If the
Daily Scrum results in decisions that affect others (like the Product Owner), they can be
consulted by the Development Team afterward.

So, although the Scrum Master can participate during the Daily Scrum, this is certainly
not required by Scrum.

Possible Problems
Having the Scrum Master present during every Daily Scrum is associated with a number
of ‘smells’ that may indicate problems in how Scrum is applied:

• The Scrum Master acts as a manager of the team, and uses the Daily Scrum to
distribute work and make decisions on behalf of the Development Team;
• The Development Team does not support or commit to working with Scrum, and
needs the Scrum Master to ‘make sure it happens’. In this case, the deeper
motivation to work with Scrum needs to be addressed;
• The Development Team may be depending on the Scrum Master to facilitate
communication within the Development Team. This impedes the ability of the
Development Team to learn how to self-organize;
• The Scrum Master uses the Daily Scrum to feel meaningful. Being a servant
leader, the success of a Scrum Master often manifests in indirect ways
(improvement over time, good atmosphere, learning). For some Scrum Masters,
the Daily Scrum provides an opportunity to take the stage and have a visible
contribution - even though it does not benefit the Development Team for the
reasons stated above.
Tips

The following tips are helpful to make the Daily Scrum more effective (as Scrum
Master):

• Reiterate the purpose of the Daily Scrum at the start;

• Take a (literal) step back during the Daily Scrum, placing yourself outside of the
Development Team;
• Limit yourself to only asking open questions during the Daily Scrum;
• Limit yourself to only asking questions related to transparency, inspection and
adaptation: “How does this new insight affect our Sprint Goal?”, “What new work
needs to be made transparent?” or “What can we today to help each other
achieve the Sprint Goal?”;
 • Don’t actively facilitate the Daily Scrum by asking every member to answer the
three questions of the Daily Scrum. Instead, let people decide who goes next;
• Don’t attend the Daily Scrum. Observe what happens afterward;
• Ask someone in the Development Team to facilitate the Daily Scrum;
• Let the Development Team choose the starting time and location. It’s their event.
Therefore let them choose the time that suits them best. This increases the
feeling of ownership and encourages the team to start on time.
Closing

In this blog post, we’ve described the myth that the Scrum Master should always be
present during the Daily Scrum. We’ve offered the perspective from the Scrum Guide,
described some examples of possible problems in how Scrum is applied and shared
tips & tricks on how to make the Daily Scrum more effective.

What is your opinion about this myth? We are always eager to learn from your
experiences as well!

Want to separate Scrum from the myths? Join our Professional Scrum Master-courses
(in Dutch or English). We guarantee a unique, eye-opening experience that is 100%
free of PowerPoint, highly interactive and serious-but-fun. Check out our public
courses (Dutch) or contact us for in-house or English courses.
Sprint Review: Much More Than Just A Demo

Sprint Review or a Demo?

Many of those practicing Scrum mistakenly call the Sprint Review a Demo. Is it just a
matter of terminology? From my point of view, the Sprint Review is the most
underestimated Scrum Event, and for many companies, its potential is yet to be
revealed. It is true that the Demonstration or Demo is an essential part of the Sprint
Review, but it isn't the only one.

The Sprint Review is much more than just a Demo. Let’s find out why.

Who attends the Sprint Review:

The Scrum Team and stakeholders (users, other teams, managers, investors, sponsors,
customers, etc.) One could say that we invite the whole world to the Sprint Review and
this is absolutely true.

How the Sprint Review Is Conducted:

• The Product Owner opens the meeting and tells the attendees what the
Development Team completed during the current Sprint (what has been "Done"
and “not Done”).

• The Development Team demonstrates the "Done" functionality (Demo), answers

the questions and discusses problems they met on their way.

• The Product Owner discusses the current state of the Product Backlog,
marketplace changes, and forecasts the likely release dates.
 • The attendees collaborate on the Product Backlog Items, which can be
completed during the next Sprint. Thus, the stakeholders get a shared
understanding of the future work.

• A review of the budget, timeline, potential capabilities follows.

The Opportunity To Inspect And Adapt.

Sprint is one of the five official Scrum Events and is an opportunity for the Scrum Team
to practice empiricism. Here is a short summary of what we inspect and adapt during
the Sprint Review.

Inspect: Sprint, Product Backlog, Increment, Marketplace, Budget, Timeline,

Capabilities.

Adapt: Product Backlog, Release Plan.

Inspecting Is Much More Than Just An Increment.

The Sprint Review is not just about product demonstration, it is an inspection of the
completed Sprint, the Product Backlog and the marketplace. Also, it is a place for
reviewing budgets, timeline and capabilities. Each Sprint is an important risk mitigation
tool and the Sprint Review is a decision point for the Product Owner.

Each Sprint can be the last one. The Product Owner makes a formal decision regarding

financing the next Sprint during the Sprint Review.

Here are some decisions that can be formally made:

• Stopping/Pausing the development

• Financing the next Sprint

• Adding team(s) with an assumption that it will speed up the development

• Releasing Increment (can be done anytime during the Sprint)

Is My Sprint Review Good Enough?

Scrum is based on iterative and incremental development principles, which means

getting feedback and making continuous updates to the Product Backlog. Unfortunately,
teams often forget about it.

The Sprint Review is a great tool for getting feedback, while the number of changes to

the Product Backlog after the Sprint Review can be an important indicator of how

healthy your Scrum is.

Why Many Scrum Teams Don't Go Beyond Demo

Many teams/companies underutilize the entrepreneurial spirit of Scrum and its concept
where the Product Owner is a mini-CEO of the Product. Very often, stakeholders attend
only the Increment demonstration (usually done using a projector) with few questions
asked and then everybody leaves shortly afterwards. This may happen for several
reasons:

• The Product Owner doesn't actually "own" the product, cannot optimize the ROI
or make strategic decisions about the product, and is, in fact, a Fake Product
Owner (FPO). During the Sprint Review, stakeholders (with actual Product
Owner among them) often "accept" the Scrum Team's work.

• The company's business and development departments continue to play the

"contract game" with predefined scope and completion dates. In this case, the
Sprint Review inevitably becomes a status meeting.

• Superficial Scrum implementation at the company.

• The Product Owner doesn't collaborate enough with stakeholders.

• This is a case of “fake Scrum”, when the Scrum Team handles only a part of the
system with inputs and outputs and not the real product. There is nothing to show
and nothing to give feedback on.

Good Sprint Review Practices

• An informal gathering with coffee and cookies that looks more like a meetup,
often held as an Expo or a Review Bazaar.

• The Product Backlog is updated after/during the Sprint Review.

• The meeting is often attended by the end users.

• The Development Team communicates directly with end users and stakeholders
and gets direct feedback from them.

• The "Done" product is showcased on workstations where the stakeholders can

play with the new functionality.

Signs of An Unhealthy Sprint Review

• A formal/status meeting.

• The new functionality is demonstrated only in a slide show.

• The Product Owner "accepts" the work completed by the Development Team.
 • The Development Team isn't (fully) present.

• Neither are stakeholders and/or end users.

• The demonstrated functionality does not meet the Definition of “Done”.

• The Product Backlog is not updated. The Scrum Team works with a predefined
scope.

• The stakeholders "accept" the completed work from the Product Owner.

The Bottom Line

Well, I wrote quite a lot. Let's sum it up.

• The Sprint Review is more than just a Demo. The Sprint Review is a place to
discuss the marketplace changes, examine the completed Sprint as an event,
update the release schedule, discuss the Product Backlog and the possible focus
for the next Sprint. This is where the dialog between the Scrum Team and the
stakeholders takes place and feedback on product Increment is obtained.

• The number of changes to the Product Backlog can be an important sign of how
healthy your Scrum is.
Scrum Glossary

This glossary is meant to represent an overview of Scrum-related terms. Some of the

mentioned terms are not mandatory in Scrum, but have been added because they are
commonly used in Scrum. To learn more about the Scrum framework, to identify which
of these terms are required elements of Scrum and to understand how the mentioned
elements are connected, we highly recommend that you reference the Scrum Guide™.

To learn more about terms specific to software development teams using Scrum and
agile software development techniques, reference the Professional Scrum Developer
glossary.

Burn-down Chart: a chart which shows the amount of work which is thought to remain
in a backlog. Time is shown on the horizontal axis and work remaining on the vertical
axis. As time progresses and items are drawn from the backlog and completed, a plot
line showing work remaining may be expected to fall. The amount of work may be
assessed in any of several ways such as user story points or task hours. Work
remaining in Sprint Backlogs and Product Backlogs may be communicated by means of
a burn-down chart. See also: Burnup Chart

Burn-up Chart: a chart which shows the amount of work which has been completed.
Time is shown on the horizontal axis and work completed on the vertical axis. As time
progresses and items are drawn from the backlog and completed, a plot line showing
the work done may be expected to rise. The amount of work may be assessed in any of
several ways such as user story points or task hours. The amount of work considered to
be in-scope may also be plotted as a line; the burn-up can be expected to approach this
line as work is completed.

C
Coherent/Coherence: The quality of the relationship between certain Product Backlog
items which may make them worthy of consideration as a whole. See also: Sprint Goal.

Daily Scrum: daily time-boxed event of 15 minutes for the Development Team to re-
plan the next day of development work during a Sprint. Updates are refl ected in the
Sprint Backlog.

Definition of Done: a shared understanding of expectations that the Increment must

live up to in order to be releasable into production. Managed by the Development Team.

Development Team: the role within a Scrum Team accountable for managing,
organizing and doing all development work required to create a releasable Increment of
product every Sprint.

Emergence: the process of the coming into existence or prominence of new facts or
new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.

Empiricism: process control type in which only the past is accepted as certain and in
which decisions are based on observation, experience and experimentation. Empiricism
has three pillars: transparency, inspection and adaptation.

Engineering standards: a shared set of development and technology standards that a

Development Team applies to create releasable Increments of software.

F
Forecast (of functionality): the selection of items from the Product Backlog a
Development Team deems feasible for implementation in a Sprint.

Increment: a piece of working software that adds to previously created Increments,

where the sum of all Increments -as a whole - form a product.

Product Backlog: an ordered list of the work to be done in order to create, maintain
and sustain a product. Managed by the Product Owner.

Product Backlog refinement: the activity in a Sprint through which the Product Owner
and the Development Teams add granularity to the Product Backlog.

Product Owner: the role in Scrum accountable for maximizing the value of a product,
primarily by incrementally managing and expressing business and functional
expectations for a product to the Development Team(s).

Ready: a shared understanding by the Product Owner and the Development Team
regarding the preferred level of description of Product Backlog items introduced at
Sprint Planning.

Refinement: see Product Backlog Refi nement

S
Scrum: a framework to support teams in complex product development. Scrum consists
of Scrum Teams and their associated roles, events, artifacts, and rules, as defi ned in
the Scrum GuideTM.

Scrum Board: a physical board to visualize information for and by the Scrum Team,
often used to manage Sprint Backlog. Scrum boards are an optional implementation
within Scrum to make information visible.

Scrum Guide™: the defi nition of Scrum, written and provided by Ken Schwaber and
Jeff Sutherland, co-creators of Scrum. This defi nition consists of Scrum’s roles, events,
artifacts, and the rules that bind them together.

Scrum Master: the role within a Scrum Team accountable for guiding, coaching,
teaching and assisting a Scrum Team and its environments in a proper understanding
and use of Scrum.

Scrum Team: a self-organizing team consisting of a Product Owner, Development

Team and Scrum Master.

Scrum Values: a set of fundamental values and qualities underpinning the Scrum
framework; commitment, focus, openness, respect and courage.

Self-organization: the management principle that teams autonomously organize their

work. Self-organization happens within boundaries and against given goals. Teams
choose how best to accomplish their work, rather than being directed by others outside
the team.

Sprint: time-boxed event of one month or less, that serves as a container for the other
Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
Sprint Backlog: an overview of the development work to realize a Sprint’s goal,
typically a forecast of functionality and the work needed to deliver that functionality.
Managed by the Development Team.

Sprint Goal: a short expression of the purpose of a Sprint, often a business problem
that is addressed. Functionality might be adjusted during the Sprint in order to achieve
the Sprint Goal.

Sprint Planning: time-boxed event of 8 hours, or less, to start a Sprint. It serves for the
Scrum Team to inspect the work from the Product Backlog that’s most valuable to be
done next and design that work into Sprint backlog.

Sprint Retrospective: time-boxed event of 3 hours, or less, to end a Sprint. It serves

for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted
during the next Sprint.

Sprint Review: time-boxed event of 4 hours, or less, to conclude the development work
of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment
of product resulting from the Sprint, assess the impact of the work performed on overall
progress and update the Product backlog in order to maximize the value of the next
period.

Stakeholder: a person external to the Scrum Team with a specifi c interest in and
knowledge of a product that is required for incremental discovery. Represented by the
Product Owner and actively engaged with the Scrum Team at Sprint Review.

Technical Debt: the typically unpredictable overhead of maintaining the product, often
caused by less than ideal design decisions, contributing to the total cost of ownership.
May exist unintentionally in the Increment or introduced purposefully to realize value
earlier.

Values: When the values of commitment, courage, focus, openness and respect are
embodied and lived by the Scrum Team, the *Scrum pillars* of transparency, inspection,
and adaptation *come to life* and *build trust* for everyone. The Scrum Team members
learn and explore those values as they work with the Scrum events, roles and artifacts.
Download the Scrum Values Poster

Velocity: an optional, but often used, indication of the amount of Product Backlog
turned into an Increment of product during a Sprint by a Scrum Team, tracked by the
Development Team for use within the Scrum Team.
Myth 2: The Sprint Backlog can’t change during the Sprint

Scrum is intended as a simple, yet sufficient framework for complex product delivery.
Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology.
Instead, Scrum provides the minimal boundaries within which teams can self-organize
to solve a complex problem using an empirical approach. This simplicity is its greatest
strength, but also the source of many misinterpretations and myths surrounding Scrum.
In this series of posts we - your ‘mythbusters’ Barry Overeem & Christiaan Verwijs - will
address the most common myths and misunderstandings. PS: The great visuals are
by Thea Schukken.

Myth: The Sprint Backlog can't change during the Sprint

The myth is that the Sprint Backlog is fixed during the Sprint. The Development Team
commits itself to implement all the items on the Sprint Backlog. Changes are not
allowed during the Sprint; no work can be added or removed. This offers the team
the necessary focus to fulfil their given commitment.

Why is this a myth?

Busting the Myth

The Sprint Backlog represents the work that a Development Team needs to pull from
the Product Backlog to achieve the Sprint Goal. The Sprint Goal is an objective set by
the Scrum Team during Sprint Planning and captures the hypothesis that the team
wants to test, a goal it wants to achieve or an experiment to run. Although the Sprint
Goal is fixed during the Sprint, the Sprint Backlog is not. This would be unwise
considering the core premise of Scrum: we can't create detailed plans for the future.
Even if that future is a single Sprint, it is entirely possible that new insights or
impediments emerge as the Development Team works through the Sprint Backlog.

A team might learn that a technology they picked does not perform as expected. Or a
key feature needed to reach the Sprint Goal was missed during the Sprint Planning. As
issues emerge, changes to the Sprint Backlog may be warranted in order to reach the
Sprint Goal. The Development Team will then re-negotiate the Sprint Backlog with the
Product Owner. In short; a Sprint Backlog is flexible, as long as changes do not
distract from the focus on the Sprint Goal.

The Daily Scrum presents Development Teams with an excellent opportunity to inspect
and adapt upon their progress to the Sprint Goal and make adjustments to the Sprint
Backlog when deemed necessary.

About Commitments and Forecasts

Related to this myth, the Scrum Guide has changed a couple of years ago. In the
context of the Sprint Backlog, the word “commitment” was replaced by “forecast”. It
describes the Sprint Backlog as a forecast by the Development Team about the
functionality that will be part of the next Increment and the work needed to deliver that
functionality into a “Done” Increment. This underscores that insights and unexpected
issues are likely to emerge during development - even within a single Sprint.

However, commitment is still relevant for the Development Team; they commit
themselves to:

• Fulfil the Sprint Goal;

• Delivering working, high-quality and usable software that meets the expectations
of the customers and users;
• Working only on the Product Backlog items with the highest value;
• Focus on continuous improvement, learning, and technical excellence;
• Continuously inspect and adapt, by which empiricism is supported;
• Collaborate with all the business people involved;
• The values and elements that build up the Scrum framework.
Where the Sprint Backlog is the expected output, the Sprint Goal is the desired outcome
that we want to achieve. Instead of trying to cram as much as we can into a Sprint, our
goal should be to reach the desired outcome (the Sprint Goal) with the least amount of
output (Sprint Backlog).

Embrace the emerging nature of the Sprint Backlog. Encourage the Development
Team to change, modify and improve the Sprint Backlog during the Sprint. If new work
is required, the Development Team adds it to the Sprint Backlog. If work proves to be
unnecessary, the Development Team removes it from the Sprint Backlog. It’s up to the
Development Team to apply these changes and inform the Product Owner if this is
considered necessary. Any changes done to the Sprint Backlog are done with achieving
the Sprint Goal in mind and building a “Done” Increment.
Closing

In this blog post, we’ve described the myth that the Sprint Backlog is fixed during the
Sprint. We’ve busted this myth by offering the perspective from the Scrum Guide and
describing the difference between forecast and commitment.

What is your opinion about this myth? We are always eager to learn from your
experiences as well!
A Typical Sprint, Play-By-Play

In this introductory-level article we look at the mechanics of a Sprint, and at how team
members are expected to collaborate in order to produce a release-quality increment.

The first day: Sprint Planning

The whole team, including the Product Owner, meet on the first day of the Sprint and
conduct a Sprint Planning session. This is the very first thing to happen as soon as the
Sprint commences.

Preparation

Sprint Planning ought to be prepared for. The most important preparation is to ensure
that the Product Backlog has been refined to an appropriate level of detail, with
estimates and acceptance criteria (this is the purpose of Product Backlog Refinement).
Next, the Product Owner should have ordered the work on the Product Backlog, and
have a general idea of how to negotiate a valuable Sprint Goal with the team. The
options for negotiating a Goal should also have been considered during Refinement,
and reflected in backlog ordering. Also, the team should have an idea of their capacity
for this Sprint, which is to say, how much work they believe they can take on. They may
be able to use their experience with previous Sprints to help them ascertain the size of
this budget.

First plan the value that will be delivered

Each Sprint should result in a valuable increment of completed work, fit and ready for
immediate release. The Product Owner is wholly accountable for what “value” means,
and ought to have ordered the Product Backlog in such a way that value can be
maximized by the team, sprint-by-sprint. The first thing the team must do is therefore to
plan which items from the Product Backlog should be worked on in this Sprint, so that
the best value can be delivered by the end of it.

To do this, the team work with the Product Owner to select the most valuable items from
the Product Backlog which fits their projected capacity for the Sprint. Bear in mind that
each item on the Product Backlog ought to have been given an estimate by the team,
so they will know roughly how much work is likely to be involved.
Be sure to agree a Sprint Goal

This selection of work should be cohesive, and not just a grouping of unrelated and
disparate items. Remember that a Sprint is a time-boxed opportunity to achieve
something significant. For example, by the end of the Sprint a coherent feature may
have been delivered, or a significant risk will have been mitigated. The Sprint Goal is a
simple expression of this purpose, of the overarching significance of the work selected,
and the coherence behind the selection.

A good Sprint Goal will allow the team to demonstrate focus and commitment, and allow
collaboration and the re-planning of work so it is met.

Next plan how the work will be done

A Sprint Backlog is more than just a selection of work with an end goal in mind. It is also
a plan for how that goal will be achieved, and how the associated work will be
performed. This can be done by identifying and ordering the technical tasks that are
likely to be involved. In effect the Sprint Backlog is a plan for meeting the Sprint Goal,
and a forecast of the work that will have to be done.

The Product Owner does not need to be present for this part of Sprint Planning, as it is
up to the team to plan this forecast at a technical level. However, the Product Owner
should be available, even if only remotely, to answer any questions the team may have,
and to provide any clarification that may be needed about the scope of the work. If more
than one release is expected during the Sprint, this should be agreed with the PO and
accounted for in the Sprint Backlog.

By the end of Sprint Planning, a team should be confident that it has made a good
forecast of the work that will be needed to meet the Sprint Goal. It will have captured
that plan in the Sprint Backlog which the team wholly owns. The team should be able to
begin implementing that plan immediately and with a clear understanding – such as a
Sprint Burndown - of how much work remains at any given point.

Each day, every day

Once the team have planned their Sprint Backlog they can start work. If they have
planned things out as tasks, they will collaborate with each other, as a team, to make
sure that those tasks are completed. They’ll be able to track their progress by using
their task board and their Sprint Burndown of work remaining.

Each team member will be sure to keep the Scrum Task Board and the Sprint Burndown
updated, so the information can be relied upon by others. An information radiator should
always tell the truth.

Hold a Daily Scrum

Every working day, at the same time, the Development Team will meet and plan what
they will do to bring them closer to the Sprint Goal. This meeting is called the Daily
Scrum and it should never take more than 15 minutes.

Only Development Team members should participate, as the plan of work belongs
entirely to them. It is a time-boxed opportunity to re-plan the Sprint Backlog as a result
of new discoveries and lessons learned during the Sprint. The whole team should
participate. Each team member should be able to account for:

• What they did yesterday to help the team meet the Sprint Goal
• What they intend to do today to help the team meet the Sprint Goal
• Any impediments which are getting in their way
By the end of the Daily Scrum, the team should have a clear plan for the next 24 hours
and an understanding of how they will need to collaborate in order to achieve it. They
should also have a list of any impediments which require the Scrum Master’s attention.

Refine the Product Backlog

In Scrum, Product Backlog Refinement is not a formal event but an ongoing activity -
the process of adding detail, order, and estimates to Product Backlog Items such as
User Stories. It’s up to Scrum Teams themselves to decide how often to do this,
although it’s certainly a good idea for them to build refinement into their daily routine.
Refinement shouldn’t take more than 10% of a team’s total time during a Sprint. For
most teams, half an hour a day may be adequate although some may prefer to spend
an hour or two a couple of times a week. The important thing is to make sure that the
Product Backlog is refined in a timely manner so that Sprint Planning can occur without
impediment. The whole team, including the Product Owner, should participate.

A refinement session typically begins with the Product Owner presenting the current
Product Backlog to the team. The backlog may be held in a number of forms, such as
an electronic Scrum Board or other collaboration tool, or it may simply be a
spreadsheet. A projector or shared screen can be very useful.
The team start at the top of the Product Backlog and work their way downwards,
refining each item in turn. They’ll examine each one and discuss its scope, and the
acceptance criteria that will be necessary for its completion. Each item will then be
estimated using a technique such as Planning Poker. A large item may be broken down
into smaller ones which capture greater detail. Epics may be decomposed into user
stories, for example.

The team stop once the session’s time-box runs out. They will recommence where they
left off the next time, eventually starting at the top again so the backlog is kept up to
date.
Always collaborate

In agile practice, team members never work in isolation – if they did, they wouldn’t be a
team. In fact, teamwork is so important that the role is Development Team rather than
Developer.

This means that each Development Team member must collaborate with his or her
peers throughout the day, as they are jointly responsible for the progress of work. Any
problems or failures are jointly owned by the team, as well as their successes.
Collaboration is not something which is restricted to events such as the Daily Scrum,
but applies to everything the team does throughout each entire Sprint.

Examples of collaboration include:

• Helping peers to complete work in progress before bringing in new work from a
backlog
• Pair programming, such as taking it in turns to use the keyboard and helping and
checking each other’s work
• Peer review
• Asking for help, and being keen to give it
• Going to where the work is and helping, instead of waiting for work to be passed
over to them
• Making sure that all work does in fact meet the Definition of Done
• Calling a Scrum in order to resolve problems which need the team’s immediate
attention
• Raising impediments to the Scrum Master so they can be handled in a timely
manner
• Updating a Scrum Task board and burndown chart so that the information is up-
to-date and can be relied on
• Skill and knowledge sharing
The final day: Review and Retrospective
Hold a Sprint Review

If a team has collaborated efficiently, they’ll have worked together to meet the Sprint
Goal, managing any risks and adjusting their plans as necessary. They’ll have
demonstrated control throughout the Sprint through an even burndown of work
remaining, where each member saw it as their personal responsibility to help complete
work in progress. They’ll have a valuable increment to demonstrate to the Product
Owner and any invited stakeholders. A Review is something a team should look forward
to.

It’s also something a team must prepare for. Enough time must be allowed for a
demonstration of the work which has been performed. Tasks may be planned on a
Sprint Backlog for this purpose, to make sure that the Review does justice to the work
done and the value which is now available. Also, if the Product Owner thinks it would be
a good idea to invite stakeholders, then those invitations ought to have been sent. The
review is an opportunity to celebrate the work which has been done and to showcase
their accomplishments, so confidence is inspired and a continued investment in the
team might be justified.

A Sprint Review is also an inspect-and-adapt opportunity. It’s a good time for the
Product Owner to explain how well the product is performing, to get feedback first-hand
from any invited parties, and to draw any lessons which might be used to improve the
Product Backlog further. If any work has not been completed, for whatever reason, then
this will also be reviewed and re-estimated on the Product Backlog for possible planning
into future sprints.

Then conduct a Sprint Retrospective

The Sprint Review looked at the Product and the value delivered, at the work which has
been done, and honestly and candidly at any work which wasn’t done, whatever the
reason.
The next thing to do is to conduct a Sprint Retrospective. A Retrospective considers the
process which the team is following. Are they working as effectively as they can? It’s
generally best to hold the Retrospective immediately after the Review, because the
former can introduce ideas for consideration in the latter.

The whole Development Team, the Product Owner, and the Scrum Master must all
attend the Retrospective, because everyone is jointly responsible for the success of the
team’s work. It’s really important to have a free and open session which gets to the
heart of any problems and identifies actions which will help to resolve them. A
Retrospective may begin with the following declaration:
“Regardless of what we discover, we understand and truly believe that everyone did the
best job they could, given what they knew at the time, their skills and abilities, the
resources available, and the situation at hand.”

In a “Retro”, everyone has an equal voice. One approach, which the Scrum Master may
facilitate, is to identify:

• Things which went well

• Things which didn’t go so well
• Ideas for improvement
• Shout-outs for team members who did something exceptional
Establishing a time-line can help jog attendees’ memories about significant events
during the Sprint.
Six Reasons Why You Need to Pay More Attention to the
Sprint Goal

The Sprint Goal is an important part of Scrum. It's like a burning torch that unites the
Development Team and helps it move forward during the Sprint. However, the Sprint
Goal is not discussed very often, and in this article, I would like to talk about the deep
importance of this component.

First, let's look in the Scrum Guide and see how it describes the Sprint Goal.

The Sprint Goal is an objective set for the Sprint that can be met through the

implementation of a Product Backlog. It provides guidance to the Development Team

on why it is building the Increment. It is created during the Sprint Planning meeting. The

Sprint Goal gives the Development Team some flexibility regarding the functionality
implemented within the Sprint. The selected Product Backlog items deliver one

coherent function, which can be the Sprint Goal. The Sprint Goal can be any other

coherence that causes the Development Team to work together rather than on

separate initiatives (Scrum Guide, 2016).

We can see that the Sprint Goal gives both flexibility and coherence. I'll try to explain
these ideas while adding some important comments.

The Sprint Goal gives the Development Team some flexibility. When developing
innovative products, things often don't go as planned. If a team knows their Sprint Goal,
they can regroup and achieve the Goal, even with less functionality than planned.

Let's say that the planned Sprint Goal states:

Implement the functionality for user registration.

At the end of the Sprint, the team realizes that they have no time for implementing the
Restore Password feature. However, the goal can be achieved because the end users
can sign up and create their profiles. The only thing is that they will have to memorize
their passwords for a while ;)

The Sprint Goal gives sense to the tasks and motivates the Team. People tend to
be more enthusiastic and enjoy their work when they understand what it's for and how
they contribute to the common cause. For example, a Sprint Goal can be worded as
follows:

Launch a partnership program (traders) for acquiring new clients and increasing the

company's earnings.

The Sprint Goal unites the Development Team. There is a Russian fable about a
Swan, a Pike and a Crawfi sh. For some obscure reason, this unlikely threesome
needed to pull a cart; no wonder they did not succeed. "When partners can't agree, their
dealings come to naught", concludes the author. That's no way to do things. The Sprint
Goal lays the ground for teamwork; it explains why team members need to work
together as one instead of pursuing separate initiatives. The two examples provided
above show a clear focus that unites the team.

The Sprint Goal helps in managing risks. Each Sprint can be considered a project
with a fi xed budget and date. The Sprint Goal indicates the risk that the Scrum Team
mitigates during the current Sprint. The risk can be associated with functionality,
technologies, human factors, the external environment, etc.

Imagine a context where the Scrum Team sees a great technological risk and states the
following Sprint Goal:

Test technology X and technology Y, make a final decision based on the results.

During the Sprint, the Development Team may implement two prototypes in order to
lower the risk of a worse decision.

The Sprint Goal helps with focus and making decisions. The Sprint Goal helps
highlight the essence and ignore everything irrelevant during the Sprint. When a new
task appears, ask yourself if it is related to the current Sprint Goal. If yes, the Scrum
Team can consider including it into the Sprint Backlog. If no, there is a solid reason to
postpone it. Let's imagine that during the Daily Scrum on the third day of Sprint, a
developer says he found out how to fi x a bug that the team couldn't reproduce over the
last few weeks. Apparently, this should take no more than three hours. However, the
team reminds him that the bug has a lower priority than the tasks at hand. Moreover, it
is not related to the current Sprint Goal, so it will be fi xed during the next Sprint if the
Product Owner puts it on top of the Product Backlog.

The Sprint Goal helps manage stakeholders' expectations. Stakeholders don't need
to know all the details of the plan that the Scrum Team is working on during the Sprint.
Often, the Sprint Goal is enough to satisfy their curiosity. Let's say the team
implemented a new traders' partnership program and the next Sprint Goal says,

Partners need to get remuneration according to the selected earnings model.

Will the stakeholders understand what the Scrum Team will be working on during the
next Sprint? I'm sure they will.

I hope these six reasons are enough to convince you that the Sprint Goal is an
extremely important part of the Scrum. In the next article, I will show eight ways to
phrase it.
Scrum from the trenches - the Sprint Goal

In the "Scrum from the trenches" blog post series I like to address topics that I
encounter in practicing Scrum in the real world, with real teams. Sharing where theory
comes into practice, what challenges teams encounter along the way and ways to help
Scrum practitioners use the power of empiricism to overcome these challenges.

The Sprint goal

We'll start out this series with addressing common challenges regarding the Sprint goal.
Let's first briefly introduce the Sprint goal as a concept in Scrum.

A goal is mentioned 37 times in the Scrum guide in different contexts. Although it's not
part of the core elements of Scrum (Roles, Events and Artifacts), having a Sprint goal is
of great importance for achieving your overall business objectives and customer
satisfaction.

The Sprint goal is crafted in during the Sprint Planning and fosters collaboration
between the Development Team and the Product Owner, creating a shared
responsibility on achieving that goal. It creates means of conversation about what to do
next. And above all, it helps bring focus to the Sprint.

During the Sprint, the Sprint goal is transparant for all to see. This is important to be
able to work towards that goal, for instance during the Daily Scrum. During the Daily
Scrum the Sprint goal should be the main topic of conversation, creating a plan for the
next 24 hours towards that goal.

The Sprint Backlog should consistently reflect the current progress of work towards the
Sprint goal and remaining work to be done. If there is work that is obstructing
completion of the Sprint goal, it best be removed from the Sprint Backlog.
Challenges with the Sprint goal

So far for the theoretical part. The question now is, what challenges do you encounter
that relate to this subject? I have my own experience with teams and also did some
inquiries in the Scrum community to find out what teams are struggling with. Let's take a
look at some of these real life - from the trenches - challenges!

With each of these challenges I share some things you could try to see if they help you
improve. Remember, Scrum is an empirical process control mechanism. How to resolve
and improve depends heavily on the context of the team and organisation. Some things
may work for a specific team and not for yours. Or it's not the right time. But revealing
them to the team you are working in or with may help you improve.

Let's get started:

Challenge #1: There is no Sprint goal

When I started using Scrum years ago as a developer and Scrum Master, the Sprint
goal was not top of mind for me. There were all kinds of other challenges way more
prominent than not having a Sprint goal. If the work got done, we were satisfied.

Asking around to common problems, this is one that pops up quite often. Not having a
Sprint goal might not block you from delivering a releasable increment or delivering
value for your customers. However, a lot is gained when teams have focus on the goal
of the Sprint.

Tips to help improve this

The first major question that needs answering in this case is: what's the reason there is
no Sprint goal? This may be due to lack of knowledge, we simply don't know that the
Sprint goal in Scrum is significant. In this case a good conversation in your
Retrospective could help. Also, the team might need some guidance in establishing the
Sprint goal during the Sprint Planning, because mostly there also is a lack of focus. We
discuss the challenge of lack of focus later on.

Try to figure out by asking around and having constructive conversation with the Scrum
team about why there is no Sprint goal. Any one of the challenges still to be discussed
might be an underlying issue that needs to be resolved first.

Talk to the Product Owner (or if you are one, ask yourself this question): what is it that
we want to achieve at the end of this Sprint? Talk to the team about this goal. Also,
there are other stakeholders that would probably like to be able to see what the Scrum
Team delivers at the end of the Sprint. A Sprint goal makes more sense than a bunch of
Sprint Backlog Items packed together.

This is a general tip:

Be patient. Change takes time. However, don't be hesitant to experiment. People are
more eager to try something out and verifying the outcome (experiment) than they are
open to enforced changes from the outside.

Challenge #2: The work is the Sprint goal

So the next challenge to overcome, is a pitfall often taken when doing Scrum: sticking to
the "rules of Scrum", but not knowing the reason for the rule being there.

This also is something I have done. I've told the team: 'Guys, we need a Sprint goal,
because that's what prescribed by Scrum!'. And then if you are "lucky" and the team
obeys, the Sprint goal becomes: "Get Jira tickets 17322, 17323, 171400 and 17888 to
done". 'Great, we now have a Sprint goal. Back to work!'.
-or-

We take a close look at all the Product Backlog Items we selected for the Sprint and we
try to squeeze these into a sentence that sums them all up:

"Finish the authorization issues, create a procedure for capturing search queries and
make it generic, create a new theme for mobile version".

Product Backlog Items in the Sprint are the output that implement the Sprint goal,
the outcome. Meaning the Sprint goal should be leading and not the Sprint Backlog
Items.

Tips to help improve this

Product Owners should share their vision and what goals need to be achieved next.
They should talk about it, share it, get feedback on it. Then invite the Development
Team to pull work from the Product Backlog (and maybe create some Sprint Backlog
Items as well) that will achieve this goal. Share and discuss this when the plan for this
Sprint is drafted.

Often, Product Owners take the lead in Sprint Planning. And they should at first, but
then they have to let the Development Team self organize around the Sprint goal. You
might be surprised at the results!

The key in this situation is to look at the way the work is organized. Is the Product
Owner trying to keep all the stakeholders happy by giving them all a breadcrumb? Or
are the stakeholders managed and is the Product Backlog organized around functional
components that deliver value for customers at the end of the Sprint?

The Product Owner must be challenged on the status quo and the Development Team
should take ownership on the plan that should have the Sprint Goal as outcome. They
should discuss the Product Backlog Items that are taken into the Sprint and also look for
alternative ways to achieve the Sprint goal.

Challenge #3: There is no room for anything else

So the next challenge that arises happens often when we have overcome the previous
challenges. We have a Sprint Goal, it's crafted during Sprint Planning in collaboration
with Product Owner and Development Team and the goal actually makes sense.

But there is no room for anything else. All the items on the Sprint Backlog are
mandatory for accomplishing the Sprint goal. And that's a problem. Because we know
that there are problems that will occur:

• The solution thought of turns out to be a lot harder to implement;

• Production failures need fixing;
• Danny (the guy everyone relies on) is ill (again!);
• The Product Owner promised a particular stakeholder that he can get this last
minute fix in the Sprint anyway.
... and so on ...

Having a full Sprint means imminent risk in achieving the Sprint goal!

Tips to help improve this

I have had one team use a primary and secondary goal in a Sprint, so that the focus
remains on the main goal, but there is still cohesion on the rest of the Sprint. This may
or may not work for your team.

Also, having so much work on your Sprint Backlog can challenge you to do things
differently when things get tough and the Sprint goal gets jeopardized. But more likely it
will cause teams to get stressed, have more focus on the work than on the actual Sprint
goal.

Invest time in Product Backlog refinement. This will likely create better insights, multiple
ways to solve things, smaller Product Backlog Items etc.

And to conclude, yes: give yourself / the Development Team room to be creative and
solve problems.

Challenge #4: There is no focus on the Sprint goal

Having a solid, well understood, collaboratively crafted Sprint goal is great, but it's not
so great if you leave it behind
in the room where it was born and is never brought up again.
Ask yourself the question what's the use of a Sprint goal if it's never brought up again
during the Sprint?

Tips to help improve this

Focus is one of the Scrum values and therefor important on a number of levels. This is
definitely one of them. Having a goal helps create focus and this fosters collaboration.
Collaboration improves quality and ultimately, that's what we need: good quality,
valuable products for our end-users.

First step in overcoming this challenge is one of the most important things in Scrum: be
transparent. Make sure the Sprint goal is visible somewhere for everyone to see.

Secondly: talk about it. This sounds easier than it is. As soon as there is work to do we
tend to focus mainly on the work and forget the goal. Scrum Masters reading this will
recognize this. During Daily Scrum, make sure the Sprint Goal is discussed.

Make sure Sprint Backlog Items on your Sprint relevant for the Sprint goal are on top
and worked on first. Ask questions when it turns out people are working on other things.
One team I work with gives the Sprint Backlog Items that are relevant for the Sprint goal
a special color or tags them otherwise. This works for them.

Challenge #5: The goal is not a goal

The final challenge teams face that we will discus is the goal not being a goal. It's
important that the Sprint goal has a -what- focus: what do we want to achieve? We don't
need the -how- in there:

"Change the page to support HTML5 elements"

... is probably not the best Sprint goal to work on.

Tips to help improve this

First of all, if you get to this level and the other challenges are behind you,
congratulations! That's quite an achievement. Having a Sprint goal, talking about it,
having focus on it, giving room to inspect and adapt on it... you've come a long way!

This last challenge is a tough one, because there might be any number of challenges
behind this that need attention.

Are the project or product goals worked on in your company clear to all? And as for the
Sprint goal: is this contributing to the overarching goals of the company? Formulating
the Sprint goal as really technical or on the -how- axes may be caused by underlying
aspects of the organizational culture.

Maybe the Scrum roles (and responsibilities) are not clear or not practiced. For
instance: if a Product Owner is also a business analyst or a project manager, this will
influence the way we look at our goals. Or maybe the company doesn't care about goals
at all?

The Scrum Master role within Scrum is meant to reveal these organizational
impediments. It takes time, patience and asking a lot of questions. But it will help the
organization move forward toward achieving their goals.
The 11 Advantages of Using a Sprint Goal

When facilitating a Scrum Master training, the Sprint Goal is a topic that often causes a
good discussion. Participants question the background, purpose and advantages of
using a Sprint Goal. In this blog post I'll describe the concept in more detail, explain why
using a Sprint Goal is important and how to choose an efficient goal.

What is a Sprint Goal?

The Sprint Goal is an objective set for the Sprint that can be met through the
implementation of Product Backlog. Sprint goals are the result of a negotiation between
the Product Owner and the Development Team. Sprint Goals should be specific and
measurable. While the selected work for the Sprint Backlog represents a forecast, the
Development Team gives their commitment to achieving the Sprint Goal.

Could You Give Some Examples?

Although I've stated that Sprint Goals should be specific and measurable I don't mean
SMART. Just prevent the goals become to vague. But some examples might be:

• Get feature X ready for release (hereby the Sprint Goal is delivering a feature)
•
• Check if the architecture enables the desired performance (hereby the Sprint
Goal is addressing a risk)
•
• Test if users are willing to register before using the product features (hereby the
Sprint Goal is testing an assumption)
Why Using a Sprint Goal?

An effective Sprint Goal...

 1. Serves to test assumptions, address risks or deliver features

2. Ensures a focused Daily Scrum because the Development Team can use it to
inspect their progress

3. Provides guidance to the Development Team on why it is building the Increment

4. Offers flexibility regarding the functionality implemented within the Sprint

5. Helps setting priorities when "the going gets tough"

6. Fosters teamwork and teambuilding by jointly working towards a shared Sprint

Goal

7. Supports the Product Owner in creating the product roadmap

8. Stimulates Product Backlog cohesion when planning a release

9. Can be used as an instrument for stakeholder management

10. Supports a focused Sprint Planning by crafting a shared Sprint Goal

11. Enables efficient decision-making

How to Choose a Sprint Goal?

To determine what the Sprint Goal should be, Roman Pichler offers three questions
to consider:

1. Why do we carry out the Sprint? Why is it worthwhile to run a sprint? What
should be achieved?
 2. How do we reach its goal? Which artefact, validation technique, and test group
are used?
3. How do we know the goal has been met? For instance at least three of the
fi ve users carry out the usability test successfully in less than a minute

Check Roman's the Sprint Goal template for more information.

Wrap Up

In this blog post I've described the advantages of using an effective Sprint Goal. If
you're convinced about the advantages but struggle with choosing a Sprint Goal, I hope
the part based on Roman Pichler's ideas gives you some more guidance. If you've got
any other questions, feel free to share them.
Getting started with a Definition of Done (DoD)

In my last post about Professional software teams creating working software David
Corban made a good point. How do you determine what "Free from fault or defect"
means? Since that is different for each Product and may change over time you need to
focus on Quality and reflecting that quality in a Definition of Done (DoD).

Your Development Team is ultimately responsible for creating done increments of

working software. Done Increments. Done.

Your Development Team needs to decide what Done means. They need to sit down and
create a list of things that must be true for every Increment of software that they deliver.
Working Software is not specific to a PBI; it's applied regardless of PBI to the entire
delivery. Not just for each PBI.

"The increment must be in useable condition regardless of whether the Product Owner

decides to release it."

-http://scrumguides.org

If you can't ship working software at least every 30 days then by its very definition, you
are not yet doing Scrum. Since Professional Scrum Teams build software that works,
stop, create a working increment of software that meets your definition of done (DoD),
and then start Sprinting, and review what you mean by "working" continuously, and at
least on a regular cadence.

What is a Definition of Done (DoD)

You need to start somewhere, and most often we don’t have a greenfield product. Either
we are handed an existing product, or we are the team that built it and are switching to
Scrum. Wherever your product originated, the code, and thus the product, will not
currently be working software. How can it be when you don't have a definition of what
working means? So what do you do?

Before you cut a single line of code, you need to decide what done means for your
product and your company. It will be defined very differently if you are building firmware
for pacemakers or if you are creating an e-commerce portal. Here are some
characteristics of a Definition of Done:

• A short, measurable checklist - try and have things on your DoD that can be
measured, that you can test the outcome, preferably in an automated fashion.
• Mirrors shippable - While you might not have shipped your product, although
we recommended it, you should have that choice. Your Product Owner should be
able to say, at the Sprint Review: "That’s Awesome… lets ship it.".
• No further work - There should be no further work required from the
Development Team to ship your product. Any additional work means that you
were not Done, and it takes away from the Product Owners capacity for the next
iteration. Ideally, you have a fully automated process for delivering software,
and never use staggered iterations for delivery.

Your short, measurable checklist that mirrors shippable and results in no further work
required to ship your product needs to be defined. I find the best way to do this is to get
the Scrum Team (the Product Owner plus the Development Team) into a facilitated DoD
Workshop. Without a Defenition of Done we don't understand what working software
means, and without working software we cant have predictable delivery. Your Product
Owner can't reject a Backlog Item, only whether the Increment is working or not.
My first Definition of Done (DoD)

Your Definition of Done does not just magically appear, and your software does not
magically comply. Making your Software comply with your definition of done is hard
work, and while your definition of done should organically grow, you need to create the
seed that you can build on.

I recommend that you run a workshop with the entire Scrum Team, and likely some
other domain experts. If there are Stage Gates that your software has to pass after the
Development Team is Done, then you need representatives from those Gates to
participate in the workshop. Regardless of your product you likely need representatives
with the following expertise; Code, Test, Security, UX, UI, Architecture, etc. You may
have this expertise on your team, or you may need to bring in an expert from your
organisation, or even external to your organisation.

Some examples of things to put on your definition of done:

• Increment Passes SonarCube checks with no Critical errors - You will be

increasing over time, so maybe you need to say "Code Passes SonarCube
checks with no more than 50 Critical errors" then work on it over time.
• Increment's Code Coverage stays the same or gets higher - Looking at a
specifi c measure, like 90%, of code coverage is a read hearing and tells you
nothing of code quality. However, it might be advantageous to monitor and
measure for adverse change in code coverage, and we always advocate for TDD
practices.
• Increment meets agreed engineering standards - You should decide rules for
naming of methods, tests, variables and everything in-between. Start small and
add over time. Link to your agreed standards on a Wiki and continuously improve
and expand your rules. Automate if possible.
 • Acceptance Criteria for Increment pass - Making sure you at least meet the
prescribed criteria is a laudable goal and automating them with ATDD practices is
even better.
• Acceptance Tests for Increment are Automated - Make sure that you
automate all of your tests. If you think something will break, then you should have
a test for it.
• Security Checks Pass on Increment - Use an automated tool as part of your
build and check for known security vulnerabilities. You will not fi nd all of your
security issues, but at least don’t do things we know to be refl ective of poor
Security.
• Increment meets agreed UX standards - Again, have a Wiki page and make
sure that you check it twice. If you are not using an automated DoD entry, then
you need to agree as a Team that you have met the criteria.
• Increment meets agreed Architectural Guidelines - Wiki's are fantastic for
this, but automate what you can.

Whatever Definition of Done you come up with it is unlikely that your entire Product
currently meets the criteria. You are not yet doing Scrum. Before you start Sprinting, you
need to focus on making sure that your current Increment meets your new Definition of
Done. Focus on Quality, which is what the Development Team is accountable for, and
make sure that your Increment meets that new quality bar before you start. The next
Increment can only reach the quality bar of all those that came before do.

Create a Working Increment of Software that meets your definition of done and then
start sprinting. Keeping your software in a working state will require a modern source
control system that provides you with the facility to implement good DevOps practices.

Growing your Definition of Done (DoD)

It's super important that quality is always increasing, and that means that you will need
to at least reflect on your Definition of Done on a regular cadence. In Scrum, this
cadence is defined by your Sprint length, and you have a Kaizen moment at the Sprint
Retrospective. That does not mean that you don’t reflect on your DOD all the time, you
do. You reflect continuously on whether your increment currently meets your DoD, and
what you need to do to get it there. You should always be reflecting on whether your
DoD fits your needs. If your Development Team finds that something is missing from the
DoD halfway through the Sprint, then they should go ahead and add it, making sure that
they are not endangering the Sprint Goal.

You may discover that you have a performance problem with your product as David
Corban pointed out in my previous post. How do we make sure that we fix that issue?
As I see it there are two pieces to this once you are in flight. You can Scrumble (stop
Sprinting because of poor quality), and fix it, or you can integrate this new knowledge
into your product cycle.

If it is a significant issue that results in you not having working software, then you need
to stop and fix. In Scrum, this is called a Scrumble, as a reflection that the Development
Team stumbled because something is missing. You should stop adding new features
and create Working Software before you continue Sprinting and adding new features.
Once you have repaired the issue, you can increase your Definition of Done to make
sure that all future Increments meet the new requirements.

If it is less significant, you might want to keep working and add what you need to your
Product Backlog. You can then deliver improvements over the next few Sprints that
mitigate and then resolve the identified issue. Once you have resolved it, you can then
pin the outcome by adding something to your DoD.

Always look for ways that you can increase your quality. What does your
definition of done look like today?
Walking Through a Definition of Done

“Scrum begins with Done”. So remarked Gunther Verheyen, neatly synopsizing a

paradox of agile practice in four words. The assertion might seem counter-intuitive,
as though we must start by defining the end. The point being made is that knowing
when you are “Done” frames the work which must be undertaken in order to get there.
So if every book you write must have a dog, then you know you can't be finished unless
Bonzo has made an appearance.

In Scrum each iteration - or Sprint - should yield a valuable product increment of

release quality. That's the essential Bonzo moment. In fact everything really leads up to
that. An understanding of what makes an increment truly releasable - and therefore
genuinely “Done” - provides transparency over the work a Development Team plans to
do, and the tasks it brings into progress.

Why is "Done" so important? Well, incomplete work has a nasty habit of mounting up,
and without visibility of how much effort truly remains, the deficit can quickly get out of
hand. The tyranny of work which is nearly done, but not really done, can put a team in
servitude to technical debt. Team members are obliged to repay the “deficit for release”
at compounding rates of interest, as it becomes harder and harder with each Sprint to
bring that delinquent, half-finished work into a usable and releasable state. They
become indentured to debt, laboring to undo decisions which might have seemed
expedient at the time, but which compromised their work and made it of less than
release quality. Eventually the expense of fixing things, of repaying the debt, may
exceed the value to be had from the next product increment. By that time the team are
effectively insolvent.

However, if the team have a clear understanding of what “Done” means, the tyranny
which can so easily beggar them is routed and overthrown. Transparency reigns, and in
each Sprint the "Definition of Done" holds an honest court. What has truly been
delivered? Is the increment of demonstrable release quality, immediately usable, and of
actual value to stakeholders?

In short, a “Definition of Done” is fundamental to the attainment of transparency in agile

practice. Strangely though, many teams fail to recognize this connection and see
“Done” as a kind of stage-gate which, for the sake of "agility", ought to be negotiated
fast-and-loose. The disdain for agile rigor can present a real challenge. Ask a team to
share their Definition of Done, and a coach may hear vague mutterings about “unit tests
passing” or work being “checked in” or “signed off”. Inquire further as to whether this is
adequate for work to be of production quality, and the team can become defensive or
sheepish. In truth their increments may not be even close to a releasable state. There
may be months of further integration and testing, in multiple higher elevations of pre-
production environments, before that condition is achieved. Often, the team might not
have implemented Scrum at all, but faked it within the constraints of an unchanged
organization and the status quo presented by its operating model.

It can be very tempting to try and fix a lack of rigor by patching a Definition of Done with
stronger criteria. However, the definition will be poorly applied unless those terms are
clear to the team, and they are in agreement with them.

It's best to start with the little that is thought to hold and jot it down. It doesn’t matter if it
is only one or two lines on a Scrum board asserting trivia like “unit tests pass” or “code
checked in” or “accepted and signed off”. At this stage, what matters is that the
Definition of Done has begun to crystallize. The team must own a manifest view of the
standard to which they hold their work, however shoddy it may be. Only then can they
hope to improve it.

EXAMPLE DEFINITION OF DONE

Remember that a Definition of Done properly applies to an increment.

1. Environments are prepared for release

First check that no unintegrated work in progress has been left in any development or
staging environment. Next, check that the continuous integration framework is verified
and working, including regression tests and automated code reviews. The build engine
ought to be configured to schedule a build on check-in. It may also trigger hourly or
nightly builds. Also, check that all of the test data used to validate the features in the
release has itself been validated .

2. Handover to support is complete (Note: This may be elided in a DevOps context or

where the Dev Team will follow the product through to support)

All design models and specifications, including user stories and tests, must be accepted
by support personnel who will maintain the increment henceforth. Note that they must
also be satisfied that they are in competent control of the supporting environment.

3. Review Ready

Part of the work in a Sprint includes preparing for the review. Sprint metrics ought to be
available, including burn-down or burn-up charts. Any user stories which have not been
completed ought to be re-estimated and returned to the Product Backlog.

4. Code Complete

Any and all “To Do” annotations must have been resolved, and the source code has
been commented to the satisfaction of the Development Team. Source code should
have been refactored to make it understandable, maintainable and better able to
support future change. Note that the Red-Green-Refactor pattern found in Test Driven
Development is helpful here.

Unit test cases must have been designed for all of the features in development, and
allow requirements to be traced to the code implementation such as by clear feature-
relevant naming conventions. The degree of Code coverage should be known, and
should meet or exceed the standard required. The unit test cases should have been
executed and the increment proven to work as expected.

Peer reviews ought to be done. (Note: If pair programming is used, a separate peer
review session might not be required). Source code is checked into the configuration
management system with appropriate, peer-reviewed comments added. The source
code should have been merged with the main branch and the automatic deployment
into elevated environments should be verified.

5. Test Complete

Functional testing should be done. This includes both automated testing and manual
exploratory testing, and a test report should have been generated. All outstanding
defects (or incidents such as build issues) should be elicited and resolved, or accepted
by the team as not being contra-indicative to release. Regression testing has been
completed, and the functionality provided in previous iterations has been shown to still
work. Performance, security, and user acceptance testing should have been done, and
the product should be shown to work on all required platforms.

DEFICIT FOR RELEASE

"Done" criteria which are needed to effect a release, but which cannot yet be
observed, constitute a deficit. They should be enumerated here (e.g. by moving
them out of the Definition of Done).

"Better a little which is well done than a great deal imperfectly" - Plato.
Definition of Done Should include a Definition of Undo(ne)

Everyone building software products today aspire to be able to seamlessly update the
production software in a continuous manner. To be able to deploy code without the
‘normal’ friction of process controls, reviews, test departments and committee meetings.
As Martin Fowler describes in his review of Jez Humbles and Dave Farley’s books
‘Continuous Delivery’, the last mile of software delivery is often the hardest part. But is
continuous delivery really the aim or is it something more? To understand this question,
I want us to think about how our approach has evolved from Continuous Integration to
Continuous Delivery and on.

In the beginning, there was Continuous Integration (CI). Well, actually a long time after
the beginning. CI became popular with the advent of better working practices
popularized by Extreme Programming. The idea that when you finished your work you
committed that work into the main development branch, with everyone else and it was
integrated, deployed to some magical environment and then tested. I must admit, CI
changed my life. As a very average developer, I lived in my branch, my own separate
environment avoiding integration until I really had to. I polished my apples/code until I
was so sure it worked I would be tempted to show others. Integration with others was
normally a nightmare fraught with blame, fingers being pointed and problems. It broke
up my otherwise perfect job of sitting on my own solving thinking big thoughts. The work
by Martin Fowler and others made me realized that maybe if I committed integration
earlier with small chunks of stuff, my code would be better! Then automated testing and
then....

But there was a flaw – We delivered our code, even tested it, but then moving into
production was a nightmare and there was a cost. The challenges we had in integrating
the code were nothing compared to the perils of moving that code into production.
Differences in configurations and data made the likelihood of success low. To reduce the
risk, complex processes and toolchains were introduced.

Continuous Delivery was the response to this. It basically applied the ideas of CI on a
much grander scale. Let’s not just integrate and test, but let’s integrate, test and deploy
to production. Let’s strive for a continuous process and remove all waste that gets in the
way of that process. And organizations like Amazon, Facebook and others took this
mission to extremes deploying every XX seconds and creating automation to reduce the
cost and effort required.

But, then many started asking a simple question. Is the goal to release software or
actually answer questions or learn something. Along came Lean UX, or Sense and
Respond. The addition to the process of instrumentation and data gathering to provide
insights into the use of a feature. Add to that A/B testing where you released competing
features and compared the results. Continuous delivery became CD and Data capture/
analysis.

And the Scrum community embraced the idea of continuous delivery + data capture/
analysis. After all, Scrum is an empirical process. It needs continuous learning to allow
course corrections improving both the ability to deliver stuff and how the stuff is
delivered. This whole CI/CD/DCA would be documented in a simple artifact, the
Definition of Done (DoD). The DoD guides the team as they plan, do and deliver work. It
is used to communicate between teams, allowing those teams to know what the bar is
for finishing their work. So, we start to see DoDs that include not only finished software
but people using it and data coming back into the team. We start seeing discussions
about when we know if something worked or not. And, all this driven by the DoD.

But what about undone?

Recently I was trying to persuade a person at a large financial company that they
should release more frequently. His response was about risk. He said, “we can’t release
until we are really certain, or at least I have done enough that if something goes wrong I
can say I did everything I could to avoid this”. So, rather than describing the fact that
you can never do enough and that the lack of production outages is an indicator not of
success but of failure to push the envelope we started talking about something else. We
talked about could we release a little bit, and if it doesn’t work, bring it back. Could we
add an undone to our definition?

The idea is not new. Most, robust websites have the ability to rollback, but actually, it is
much harder to do with complex transactional systems. Data dependencies make
rollbacks hard and complex, but if we ever want to break the ‘we can’t release yet’ cycle
we have to start thinking about undone. How do we pull this back? Can we automate
that? Can we build that functionality in parallel to the done functionality? And frankly, it
would really help development if you included it when building the main functionality
allowing simple testing to happen over and over again without having to run DB and
server refreshes.

So, as we start into 2018 I challenge you all – You are not done until you can
undo(ne). :-)
Myth 3: In Scrum, releases are done only at the end of the
Sprint

Scrum is intended as a simple, yet sufficient framework for complex product delivery.
Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology.
Instead, Scrum provides the minimal boundaries within which teams can self-organize
to solve a complex problem using an empirical approach. This simplicity is its greatest
strength, but also the source of many misinterpretations and myths surrounding Scrum.
In this series of posts we - your ‘mythbusters’ Christiaan Verwijs & Barry Overeem - will
address the most common myths and misunderstandings. PS: The great visuals are
by Thea Schukken.

Myth 3: In Scrum, releases are done only at the end of the Sprint

Today we address a pretty persistent myth. The myth becomes apparent in statements
like “Scrum is inflexible because new releases are only possible after the Sprint
completes” or “DevOps or Kanban are better suited for us because they allow us to
release faster”. Either way, the core of the myth is that Scrum only allows teams to
release working software at the end of a Sprint, which reduces speed and flexibility if
teams are capable of doing this faster.

Busting the Myth

This myth is an example of making a framework more important than the goal, even
though it is based on a misunderstanding of the framework in this case. The purpose of
the Scrum framework is to develop products and solve complex problems by using an
empirical process that promotes rapid feedback. In short iterations, we use feedback
(internal and external) to clarify both the problem and discover the best solution. By
doing so, we avoid solving the wrong problem and/or implementing a sub-optimal
solution. Given that goal, how likely is it that Scrum would force teams to deliver working
software only at the end of a Sprint?

The purpose of the Sprint is to give the Development Team sufficient time to transform a
selection of items from the Product Backlog into a new, usable, “Done”-increment. What
constitutes “Done” varies by team, and should be defined and understood by those
involved. For some teams, an increment is “Done” when the code has been written and
lives on a shared branch in a code repository. For other teams, an increment is “Done”
when it has been deployed to some pre-production environment (staging, Q&A,
integration, etc) or to the production environment itself.

The completeness of the increment is defined by the amount of time that is still needed

to get the increment to users (e.g. to production).

The more time is needed, the less Agile the organisation is. After all, increments are
only truly valuable when they are in the hands of users. And the quality and
completeness of the feedback declines as the completeness of the Increment does.

Having said this, the Sprint represents a minimal boundary for when to deliver a “Done”
increment. There is nothing in the Scrum Framework that prevents Scrum Teams from
releasing working software throughout the Sprint, as long as the Product Owner is
involved in the decision to release. Scrum actually encourages Scrum Teams to
progressively expand the “Done”-ness of their increment to the most complete version
(e.g. released to production). This optimizes the value of the empirical process that is
the foundation of Scrum, as feedback becomes increasingly more applicable and
realistic.
Origins of the Myth

One origin for this myth is a misunderstanding of what constitutes an “Increment”. The
Scrum Guide simply defi nes it as the sum of all the Product Backlog items completed
during the Sprint. The increment can be a package of new features to be deployed in
one go at the end of a Sprint. But it doesn’t have to be. An increment can also be the
sum of functionality that has been released during the Sprint.

A second origin lies in the usage of terminology like “Potentially releasable product
increment” or “Potentially shippable product increment”. Although not intended this way,
the qualifi ers can support a belief that increments are only (potentially) “shipped” or
“released” at the end of a Sprint.

A third, and more recent, origin lies in the distinction that is sometimes made between
Scrum and DevOps. Using some version of this myth, it is argued that DevOps is
superior to Scrum because it allows teams to release working software faster. Because
DevOps does not know the concept of a Sprint, it is argued that working software can
be released whenever the team deems it “ready”.
But Scrum and DevOps are close friends, both trying to implement an empirical process
with a feedback cycle that is as short as possible. Where Scrum has a strong focus on
the process that is needed to build what stakeholders need, DevOps deals with
practices and technical enablers that make this possible. In a sense, Scrum provides a
compass and a destination to travel to, while DevOps provides sturdy boots to do so
without getting blisters or stepping on sharp stuff. They really are two sides of the same
coin.

What about the Sprint Review?

But what is the purpose of the Sprint Review if everything has already been released
during the Sprint? If your Sprint Review only consists of a demo then, yes, the event
devolves into a simple repeat of things you already know. But a demo of working
software is only a small part of the Sprint Review. The primary purpose of this event is
to inspect what was done during the Sprint and to decide what next things can be done
to optimize value.

The more “Done” the increment is, the more useful the feedback that is gathered will be.

So if the team has already released working software during the Sprint, this makes the
Sprint Review an excellent opportunity to inspect feedback from real users and adapt
based on the insights that emerge from that. The value of the Sprint Review actually
increases as the “Definition of Done” of a team moves towards “Released to
production”.

Tips

• As a Scrum Master, coach your team to continuously expand their Definition

of Done. More simply speaking, help the team to reduce the amount of work left
to do after they consider it done (e.g. testing, quality assurance, release,
documentation);
 • Invest in learning about DevOps and its associated practices, like automated
testing, infrastructure as code, virtualization, and continuous delivery. They are
critical enablers for releasing faster without compromising stability and quality;
• If your Sprint Review is only a demo, and your team is able to release throughout
the Sprint, use the Sprint Review for its intended purpose: to gather feedback
on the delivered increment, the Product Backlog, business conditions and
promote collaboration between everyone involved;
• With your team and within your organization, reflect on the amount of work
that needs to done after a team considers an increment “done” (e.q. QA,
deployment). Help both the organization and the team to change processes and
practices to decrease this amount of ‘undone’ work;

Closing

In this post we discussed the myth that Scrum Teams at best release working software
at the end of a sprint, constraining teams that are capable of releasing faster. In this
post we showed that the Scrum Framework actually encourages teams to improve their
process, infrastructure and practices to the point where releases can be done
throughout the Sprint. This maximizes the quality of the feedback of the empirical
process that Scrum tries to implement. We also offered a few tips to help you move
towards this point.

What are your thoughts on this myth? Do you agree with this post, or not at all? Let us
know in the comments.

Want to separate Scrum from the myths? Join ourProfessional Scrum Master orScrum
Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening
experience that is 100% free of PowerPoint, highly interactive and serious-but-fun.
Check out our public courses (Dutch) or contact us for in-house or English courses.
Agile Coach Toolkit #4: Effective Facilitation

As an Agile Coach, you frequently encounter situations which demand quick thinking to
get things moving in the right direction. Over time I have found few techniques which
come out handy and always keep these in my playbook in case need arise. This is the
fourth part in the series of tools that I have found useful in my role as Agile Coach –
Effective Facilitation.

Purpose – As a Scrum Master, you will need to facilitate Scrum events, decision
making, confl ict resolution and other critical discussions. This will require some
preparation and deliberation to ensure the goals are met.

Description – Facilitation is needed to ensure that the group works cooperatively and
effectively. As a Scrum Master, you will need to take care of a few aspects to help meet
the goal(s) of the discussion. Tips for effective facilitation are listed below –

1. Ensure that everyone participating in the discussion understand its purpose. You
would need to set the context at the beginning and may have to reiterate once in
a while when you see that the discussions are digressing from the context.
2. Working agreement at the beginning will help. E.g., mobile/ electronics usage,
punctuality, participant expectations, etc. Listing the Scrum values, especially if
you are going to deal with conflict resolution may help the discussion.
3. If the event/ meeting is not interactive, you may want to spend some time take
some time to find the Root Cause.
4. Create a safe environment for people to speak by ensuring that people focus on
task at hand rather than pointing fingers. Immediately interject if there are any
personal attacks.
5. Use Timeboxing to ensure that discussions are productive.
6. Balance the discussions so that introverts feel included in the discussions.
7. As a facilitator, you need to read the mood in the room to take breaks at regular
intervals to keep the energy level high for productive discussion.
 8. Be neutral in your stance and do not take sides (beware of your implicit bias
during heated discussions)
Have you used this technique in coaching your team? If yes, please share your story.
Agile Coach Toolkit #6: Building Consensus

Being a Scrum Master of a team with strong personalities can be challenging at times
especially when two or more people believe that their approach is right. Such situations
may call for Effective Facilitation to build consensus. This will help get the best out of
the productive dissent at the same time ensuring that they do not fortify into sub-groups.

There are multiple benefits of building consensus –

• Better decision-making as discussions would help uncover flaws/ situations

which individuals may not have thought of.
• Assist in better implementation of solution since everyone cooperates as it is a
team decision.
• Maintains team’s working relationship healthy by making everyone feel included.
Before going for a team discussion, it would help if you know the personalities you are
engaging with and using Root Cause Analysis in one-to-one conversation to uncover
any personality conflicts between the participants.

Steps for Building Consensus:

• Have everyone understand the meaning of giving consent by encouraging them

to think about what’s best for the entire team rather than individuals.
• Clearly articulate what needs to be decided. It may be a good idea to also layout
why the issue is being raised.
• Before pitching for lengthy discussion, do a quick poll to check if there is
consensus. If majority of the team agrees to a solution, listen to the concerns of
dissenters. Adapt the popular solution to get their points addressed so we have a
win-win solution.
 • If there is a disagreement amongst team members, allow everyone to voice their
concerns during the discussion so their ideas can be included. It would be a good
idea to list them to ensure these get addressed.
• List Scrum Values and ask people the follow them throughout the discussion.
• Leverage Timeboxing to ensure that you curtail lengthy discussions.
• For final decision, do another poll to see if majority of the team agrees. Dissenter
(if any), can serve as critical evaluator of the implementation of team decision.
This may help spot issues before rest of the team can see it.
• Ensure that the team decision is communicated at the end of the meeting.
Have you used this technique? If yes, please share your story.

A powerful technique to improve your Scrum events

Liberating Structures are 33 microstructures that allow you to unleash and involve
everyone in a group – from extroverted to introverted and from leaders to followers. In
this series of posts, we show how Liberating Structures can be used to spice up your
Scrum events. Move away from the stickies and the whiteboards for a moment, and
explore these novel facilitation techniques. If you’d like to experience Liberating
Structures first-hand, make sure to join one the ‘immersion workshops’ that are taking
place in March 2018.
1-2-4-All is one of the most applied facilitation techniques from the Liberating Structure
collection. Within 12 minutes you can engage everyone simultaneously in generating
questions, ideas, and suggestions. Regardless of how large the group is you’ll engage
every individual in searching for answers. We’ve used this technique for our trainings
with 12 participants, but also during seminars with 100+ people. It unfolds open
conversations and sifts ideas and solutions in rapid fashion. Most importantly,
participants own the ideas, so follow-up and implementation is simplified.

No buy-in strategies needed, simple and elegant!

In this post we'll explain the concept of silent self-reflection and share examples of how
we've applied 1-2-4-All within our Scrum training and coaching engagements.

Silent Self-Reflection

One of the most powerful parts of 1-2-4-All is captured in the 1-minute of silent self-
reflection. During this minute participants are invited to reflect on a shared challenge
framed as a question, for example:

• What opportunities do you see for making progress on this challenge?

• How would you handle this situation?
• What ideas or actions do you recommend?
Taking time for silent self-reflection isn’t a very common practice in meetings or
workshops. Often one or two persons are doing the talking and the rest is listening. Or
smaller groups are working with each other and continuously talking. Which is fine. Yet
before diving into a conversation about a certain challenge, taking some time for some
silent self-reflection is very useful.

It gives you the opportunity to make up YOUR mind. What do YOU think? How would

YOU deal with this situation?

Silent self-reflection should be done as a group, simultaneously. As a facilitator this is
quite a challenge. People might consider the silence a bit awkward and start making
noise or laughing nervously which distracts others. Therefore take sufficient time to
explain the purpose and importance of the first part of 1-2-4-All. Done well, a
comfortable silence is created in which the silent self-reflection will lead to the first ideas
to deal with the challenge at hand!

Uses in Scrum and workshops

We’ve used 1-2-4-All for a number of applications in (and outside) Scrum:

• As part of a Scrum training to help define learning goals. Use the 1 minute of
self-refl ection to think of personal learning goals. Share your learning goals
within pairs and afterwards a foursome. After 10 minutes the fully refi ned goals
are discussed with the group as a whole.
• During the Daily Scrum. Most Scrum Teams use the Daily Scrum to share what
they’ve done yesterday to help the Development Team meet the Sprint Goal.
What they’ll do today and if they see any impediments that prevents achieving
the Sprint Goal. Although using these questions is only a recommendation, most
teams stick to it. I’ve worked with a Scrum Team that simply answered the
question “what would be the best result we could achieve today?” By
following the 1-2-4-All steps they defi ned a plan for the upcoming 24 hours.
• During a company-wide Retrospective with participants that used to be
excessively infl uenced by their leader. With 1-2-4-All we ensured everyone was
involved and all voices and opinions we’re heard and appreciated.
• As part of the Sprint Review to gather feedback on the Increment, adapt the
Product Backlog, inspect likely completion dates and analyze marketplace
changes and potential use of the product.
• During the Sprint Retrospective to inspect how the Sprint went with regards to
people and relationships, to figure out how to make the next Sprint more
enjoyable and to adapt the definition of “Done” to increase product quality.
• As an opening exercise of a large seminar. We invited over more than 250
people to refl ect on the question “how is the Scrum Master a management
position?”. After having everyone discussed the results in pairs and foursome, we
discussed the main takeaways as a group. Within minutes the entire group was
engaged and energized!
• To gather feedback (questions, comments, and ideas) after a
presentation. Don’t ask the usual “any questions”, instead use 1-2-4-All to get
more rich feedback.
• To redesign a boring weekly meeting with management.
• To address a problem or an innovation opportunity; 1-2-4-All offers a clear
structure to discuss the challenge at hand.
Steps to use this Liberating Structure

1. Start with 1 minute of silent self-reflection by individuals on a shared

challenge, framed as a question;
2. Take 2 minutes to generate ideas in pairs, building on ideas from self-reflection;
3. Create groups of four and use 4 minutes to share and develop ideas that
you’ve discussed within your pair. Notice similarities and differences.
4. Take 5 minutes to share insights, ideas and takeaways by asking “What is one
idea that stood out in your conversation?”. Each group shares one important
idea. Repeat cycle as needed.

Picture from: http://www.liberatingstructures.com/1-1-2-4-all/

Stringing together with other Liberating Structures

A key characteristic of Liberating Structures is that they can easily combined to create
programs for entire workshops or trainings. The options are endless:

• Start with Impromptu Networking to introduce a theme, facilitate a more in-depth

reflection with 1-2-4-All;
• Use 1-2-4-ALL to discuss the questions in the final part of Appreciative Interviews
• Use the highest scoring ideas gather with 25/10 Crowd Sourcing as input for
1-2-4-ALL or Open Space Technology to translate actionable ideas into action
plans;
Tips

• Facilitate the silent self-reflection firmly, before the paired conversations;

• Invite everyone to write down their ideas during the quiet self-reflection;
• Use Tingsha bells to announce transitions;
• Stick to precise timing, do another round if needed
• In large groups, during “All”, limit the number of shared ideas to 3 or 4;
• Invite each group to share unique insights;
• Make ideas visual; use your imagination;
• Maintain the rule of one conversation at a time in the whole group.
• Try this variation: go from groups of 4 to groups of 8 with consensus in mind.
Closing

In this article we’ve shared examples of how we've applied 1-2-4-All within our Scrum
training and coaching engagements. We’re always happy to hear your experiences or
hear your suggestions. If you’d like to know more about Liberating Structures or
experience a large number of them first-hand, sign-up for one of the Liberating
Structures ‘immersion workshops’ that are taking place throughout Europe in March
2018. Barry Overeem & Christiaan Verwijs are organizing the workshop in Amsterdam,
which will be facilitated by co-inventor Keith McCandless and pioneer Fisher Qua.

Faking It: Estimates and Metrics in Scrum

"The most important metrics are: did we execute the way in which we said we would,

and did we deliver the value to the business that we had promised?" - Jamie S. Miller
In an earlier post we took a critical look at metrics and at how easily they can be
abused. Pretty much anything can be measured, and the gratuitous presentation of
numbers can give a sheen of science to an undertaking, no matter how absurd it might
really be. The problem is that a wealth of data can seem to make a convincing case,
even when the numbers have not been correlated to an hypothesis by rigorous
empirical means. Hence phrenology, although it is now understood to be a pseudo-
science, was thought to be a credible enough discipline by our forebears. Careful
measurements of people's skulls were made in an attempt to ascertain their mental
condition. Only over time, and through sceptical enquiry, did it eventually become clear
that the shape of a person's head relates very poorly indeed to their psychological
make-up. We can trust that any measurements taken were accurate and extensive, but
the data was informationally useless when applied in pursuit of this supposed science.
The measurements could never validate the phrenological method, irrespective of their
quality and quantity. Today it is dismissed as the relict superstition of a bygone age.
Simply put, an abundance of metrics, irrespective of the precision with which they might
be taken, cannot cheat a fundamentally weak correlation between hypothesis and data.
The descendants of yesterday's “bump-readers”, however, can still be found in the
board-rooms and management offices of large corporations today. With many people
under their assumed control, they demand standardized measures of productivity by
means of which employees might be compared, punished, and rewarded. Any straws
may be grasped at as long as they can be counted. Thus agile teams, which ought to be
assessed empirically by the incremental release of value, are instead gauged by the
higher-ups in terms of how much estimated work they appear to have "delivered".

Those are the bumps of today. Estimates proxy for value in this grotesque dystopia.
Measures like "story points" have become commoditized as a surrogate currency,
inviting bizarre inflationary pressures and market distortions upon any numbers which
might be arrived at. The actual provision of value to stakeholders is ignored as a
quantity too difficult to measure, and so cock-eyed metrics are appropriated in
compensation. Our work is cut out for us in trying to persuade delinquent executives to
do the right thing - to master the science of measurement - and to value the empiricism
which would allow informed decisions to be made.

A further irony is that these suspect techniques, whereby projections are made which
are based on estimates, can be used quite rationally by agile teams themselves. The
numbers represent a collaborative assessment of essential criteria, such as how much
work a team believes it can take on. Having taken these measurements the teams
which own them can then make reasoned forecasts. It is their data which they may use
for their own projective purposes, even though other stakeholders can only be assured
by the receipt of actual value. One reasonable forecast might be how much work they
think is likely to remain at a given point before one of those valuable increments is
delivered to customers. The shorter the time-period under consideration, the smaller the
leap-of-faith a team will make when determining the likelihood of a valuable, empirical
outcome.
The Sprint Burndown

The "Sprint Burndown" is an example of this sort of projective practice. It is based on

estimates, and is quite familiar to many Scrum Teams. During Sprint Planning, a
Development Team will meet with the Product Owner to agree on a selection of work
from the Product Backlog. The selection forms the basis of the Sprint Backlog, which is
a forecast of the work needed to achieve a jointly agreed Sprint Goal. This body of work
may be revised during the Sprint time-box in order to better meet the Goal. Achieving a
Sprint Goal is an accomplishment which is of signal importance in Scrum. Completing
the original forecast of work arrived at during Sprint Planning is, in truth, somewhat
irrelevant. The critical thing is to have a plan which allows the Goal to be met. It is the
Sprint Goal, and not the Sprint Backlog, which represents the more artful team
commitment. In essence, measuring how much work is left in the Sprint Backlog ought
to be nothing more than an exercise in forecasting goal actualization. It relies on having
up-to-date estimates which allow the team's progress itself to be continually estimated,
until such time as an increment is delivered, and which empirically validates the work
which has been undertaken.
A Sprint Burndown is a forecast of the work which remains to be done by a team, for
which projections can be made based on prior forecasts, and it is updated throughout
the Sprint until the goal is met. The Sprint Burndown may therefore be a projection
based on estimates, but it is understood that the measurements are made by a team for
its own purposes, and for no-one else's. It tells them whether or not they are actually on
course to provide empirical evidence, by the end of a Sprint, that the complex challenge
they have undertaken has been mitigated. External stakeholders will gauge progress
only through the evidence vouched by actual delivery. Story points and other estimates
should never proxy for this value, or be traded or commoditized. These measures are
only useful to the teams which make them, within the context of their Sprint and their
own development concerns.

Advocates of empirical process control may not be entirely satisfied with this. Even if we
accept that value will be evidenced empirically by the end of each Sprint, we still see an
attempt to measure progress using estimates. We see promissory notes for value
instead of work genuinely done. The leap-of-faith being made through a story point
Sprint Burndown is admittedly time-boxed and carefully limited, but it is a leap-of-faith
nevertheless.

Why Estimate?

So why do it? Why estimate at all? Why not just focus on completing one item on a
Sprint Backlog at a time, bringing it to release quality, and so measure progress in terms
of the rate of value honestly and genuinely delivered? If we need a burndown to show
us progress towards a goal, why not track that progress in terms of actuals rather than
estimates? Moreover, wouldn't this allow empirical process control towards that very
goal to be brought within the Sprint itself?

The argument is a sound one, and the case for "no estimates" in agile delivery has a lot
to be said for it. Certainly, we must understand and accept that measuring progress on
the basis of story points is indeed unempirical, even within the narrow confines of a
Sprint. The delivery of working features, early and often, is the only measure of
progress which can be truly satisfactory at any scale. What a story point burn-down may
reasonably do, however, is to give a team transparency over a complex event. You see,
that's what a Sprint really is. It isn't just a stream of work where independent and
discrete pieces of value are exposed to uniform pull and flow. Their joint purpose is to
meet a Sprint Goal. That goal can mitigate a very significant risk which ultimately makes
a Sprint Backlog more than the sum of its parts. Incremental release certainly doesn't
have to be deferred to the end of a Sprint, and it may indeed occur on the basis of pull-
into-production and continuous flow. However, it might only make sense to effect a
release at the end of a Sprint where a complex deliverable is at hand, and there are
multiple unknowns to be juggled. Scrum makes no prescription about any of these
scenarios or about the metrics which a trusted and self-organizing team ought to use. A
story point burn-down is an interim construct through which empirical process control
can be faked. When release happens, the fakery ends and progress is recalibrated. As
long as we understand and accept this as well, then there may not be a problem.

The Product Burndown

Now let's consider another common way of projecting delivery by means of story-point
estimates, and which is found in many Scrum implementations. The "Product
Burndown", like the Sprint Burndown, is a forecast which shows how much work is likely
to remain over time, and projected dates for its likely completion. However unlike a
Sprint Burndown - which constrains a forecast to the Sprint Backlog - a Product
Burndown attempts a forecast over perhaps the entire corpus of work. Estimates like
story-points may be used to calibrate them, and to make projections which extend over
many months, and possibly even into years of anticipated product development.
Moreover, these estimates are not intended primarily for Development Team
consumption, but rather for the benefit of senior stakeholders and other higher-ups who
wish to be appraised concerning longer-term delivery outcomes. How reasonable is it to
use Development Team estimates for these purposes? Shouldn't those people care
more about receiving value iteratively and incrementally, rather than about graphs and
charts and projections? Aren't we getting perilously close to the old bump-reading
problem, where careful measurements end up being badly used, reality is
misrepresented, and empiricism takes a back seat? In short, can executive types be
trusted with Development Team measures and metrics?

Let's remind ourselves that, at its root, the only purpose of estimation is to allow a
Development Team to figure out how much work it thinks it can take on. When those
estimates are exposed beyond the team's circle of trust we may indeed run the risk of
abuse, of story points being commoditized, of teams being compared or obliged to bid
for work using points as a cryptocurrency, and other abominations. In Scrum this is a
risk which lies squarely with a Product Owner to manage. As a member of the Scrum
Team, the Product Owner is trusted to understand and respect the Development Team's
estimates and to use any associated projections sensibly. The Product Owner will
understand the limitations of using estimates to measure progress, and the importance
of recalibrating a Product Burndown and any forecasts in light of the empirical evidence
brought about by release. If there is doubt about the ability of other stakeholders to
consume this data, then the Product Owner - as their representative, advocate and
arbiter - must decide whether or not they ought to be exposed to estimated measures
and forecasts at all. Perhaps they aren't. A Product Owner might be the only trusted
consumer of Product Burndown information. The Product Owner must be respected as
the authority who must interpret the available data, including forecasts, and who will
make decisions for optimizing and releasing product value. He or she is the one
customer representative who must lie within the Scrum Team circle of trust. It is an
unprecedented level of responsibility and accountability...and it comes with the job.
Myth 9: Story Points are Required in Scrum

Myth: Story Points are Required in Scrum

Today we address the idea that work on the Product Backlog must be estimated in Story
Points. The majority of the teams that we work with do this, and there really is nothing
inherently wrong with it. The myth begins where people misunderstand the purpose of
estimation in Scrum and Story Points become an end in themselves.

For those unfamiliar with Story Points; teams that use this technique estimate effort with
relative estimates instead of time-based estimates (e.g. hours, days). This is usually
done with a simplified version of the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 20, etc).
The numbers have no meaning in themselves, but only in relation to other items. So an
item of 5 points takes roughly twice as much effort from the team as an item of 3 points,
and so on. Several methods exist to estimate Story Points, including Planning
Poker and Magic Estimation.

Although the use of Story Points is the most widely spread technique, we could easily
generalize this post to include estimates in hours, ideal days or t-shirt sizes for that
matter.
Busting the Myth

As with previous posts, let’s start with what the Scrum Guide says on estimation.
Although it states that “work may be of varying size, or estimated effort”, it does not
prescribe how this estimation should be done. Although Scrum Teams should apply
some sort of ‘estimation’, there is no mention of Story Points, hours, ideal days, gut
feeling, t-shirt sizes or any other unit for that matter. The Scrum Guide does remind us
to use an approach that respects the complexity of software development and to not let
estimation replace the importance of empiricism itself.

So we can easily bust this myth with the Scrum Guide alone. But a more thorough
explanation helps to better understand why.

The Purpose of Estimation in Scrum

In plan-based approaches, estimates are used to arrive at budgets and to determine
delivery dates. Supposing that the estimates are accurate, they provide us with a means
to manage (financial) risks of spending either too much money or spending money on
the wrong things.

The primary purpose of estimates in Scrum is to give Development Teams a rough

sense of the amount of work they can pull into a Sprint. This requires
a conversation between members; ‘What is involved?’, ‘How should it work?’ and ‘What
work is needed?’. Although the Development Team commits to achieving the Sprint
Goal, they do not commit to completing all this work within the Sprint. As even within a
single Sprint, unexpected problems and insights are likely to emerge.

This underscores that the role of estimates is quite different in Scrum — and something
that people coming from a plan-based perspective often struggle with. Scrum is built on
the observation that software development is a very complex endeavor, making it
impossible to arrive at accurate estimates. In complex environments, what will happen
in the (near) future is largely unknown. New and better insights will emerge and
unexpected problems surface as we work together to discover both the problem and the
(most suitable) solution. Instead of relying on estimates to forecast and control what
happens in the future, we should use the empirical process of Scrum to capitalize on
change rather than control against it. As the Scrum Guide observes: “Only what has
already happened may be used for forward-looking decision-making”.

“Use the empirical process of Scrum to capitalize on change rather than control against

it.”

This provides us with four important insights with regard to estimates:

• Accurate estimates are impossible, as even the most thorough, detailed

technique can’t cover all scenarios, potential issues, insights that may emerge
 and external factors that infl uence our work. Let alone entirely unexpected
events (called ‘Black Swans’);
• An estimate can’t be a guarantee. “An estimate is simply a prediction based on
known information and input at a given point in time” — Ilan Goldstein;
• The time we spend on estimation is a form of waste. Estimates are inaccurate
at best and the work we are estimating is likely to change dramatically as our
understanding changes over time (or may even be dropped from the Product
Backlog);
• The estimates themselves are the result of a necessary conversation within
the Development Team to arrive at a shared understanding.
Instead of spending a lot of time and effort on estimation, we’re better off spending that
time on building valuable software and using the empirical process of Scrum to learn.
The question now becomes; what method of estimation is ‘just-good-enough’ to help
Development Teams select a do-able amount of work for a Sprint and getting a sense of
what is needed, while requiring as little time and effort as possible.

Time-based estimates — hours, ideal days — are one option. A major disadvantage
is that they tend to uphold the illusion of accuracy and predictability, and are often
interpreted as such. Another disadvantage is that their illusion of accuracy often drives
teams into ‘analysis paralysis’, where all details need to be discussed in-depth in order
to arrive at a detailed estimate.

“Time-based estimates uphold the illusion of accuracy and predictability.”

This is why the use of relative estimation, in particular ‘Story Points’, was popularized
by Extreme Programming. Relative estimates are not based on units of time, and avoid
all pretense of detail and accuracy. But they can provide Development Teams with a
guide on the amount of work they may be able to complete within a Sprint. Take this
example:

Suppose a Development Team has been working together for 20 Sprints. The empirical
process of Scrum has taught them that they can complete — on average — 35 points of
work (their so-called velocity). Based on what has already happened, the Development
Team has a rough sense of the amount of the work (about 35 Story Points) that they
can pull into their next Sprint. Furthermore, this empirical data (~35 Story Points) can be
used by the Product Owner to create a rough forecast for specific features or releases.
If a Development Team can take on 35 Story Points of work per Sprint, and there are
350 Story Points of work on the Product Backlog, it would not be unreasonable to
anticipate another 10 Sprints to complete the Product Backlog in its current state.

So Story Points are a lightweight approach to get a rough idea of how much work can
be completed in a Sprint. It remains a rough indicator, however. But at least it is based
on what has already happened and not on what we hope will happen. Estimation in
hours or ideal days is certainly still an option, but teams need to be aware of their
disadvantages.

Why Estimate At All?

If estimation is largely waste, it makes sense to ask: “Why even bother?”. This point is
raised by the #NoEstimates-movement. They encourage to build small chunks of work
incrementally, leading as rapidly as possible to a desired shippable product, without
spending endless hours on trying to predict the future. We don’t want to go into a
#NoEstimate debate here, but we do want to offer some alternatives to estimating
individual items:

• Use the number of items per Sprint as a guide to select a doable amount of
work for a Sprint. For example, a Development Team may know from experience
that they can complete between 6 and 8 items per Sprint. This requires that items
are broken down to about equal size;
• Use size buckets as a guide, where the Development Team classifies items in
terms of size (e.g. large, medium, small). It may know from experience that it can
complete 1 large item, 2–3 medium-sized items, and 4–6 small-sized items;
 • Simply use the combined gut feeling of the Development Team to determine if
enough work was selected for the Sprint;
Although some of these approaches may complicate forecasting based on historical
results, they are viable alternatives that fit well within the Scrum Framework and its
purpose for estimation.

Probably the most important reason why we feel that estimation is useful is that it helps
to focus the conversation within a Development Team on what is needed for a particular
item. Having to arrive at some kind of estimate, often helps to trigger the right kind of
discussions: “What is needed?”, “Can we find a simpler solution?”, “Have we considered
X?”. Estimation is not so much about the estimates, but about the discussions that it
triggers. It’s about having a conversation — ideally with the actual customer — and
creating a shared understanding.

“Estimating is often helpful, estimates are often not.” — Esther Derby

Tips

• Whatever you do in terms of estimation, make sure to do it with the entire

Development Team. The process of estimation is not solely about the resulting
number, but perhaps even more about the communication that takes place within
the team to arrive at a shared understanding of the work involved. By pooling
your expertise, creativity, and experience, you are more likely to identify potential
issues or oversights;
• Some teams want to stick to hour-based estimates because it feels ‘more real’ or
easier to estimate for them. One approach is to create time buckets with
increasing intervals (e.g. 1 hour, 2–3 hours, 3–5 hours, 5–8 hours). This
communicates more clearly the growing uncertainty as a result of a higher
estimate;
• Explore different techniques and determine what works best for your
Development Team, and requires as little effort and time as possible;
 • Don’t ask the customer what software you need to build. Instead, figure out what
problem the customer wants to solve and determine how you’ll know when it is
solved;
• With software development “I don’t know” is a valid answer to questions like “how
much will it cost” or “how long will it take”.
Closing

In this post, we busted the myth that Scrum requires work to be estimated in Story
Points. Although it is a useful technique, and used by many Scrum Teams, it is by no
means the only technique. We used this post to describe some alternatives and to
explain why Story Points became prevalent. By doing so, we also explained how
estimation fulfils a different role in Scrum than compared to plan-based approaches.

Above all, remember the quote by Esther Derby: “Estimating is often helpful, estimates
are often not.” The more complex the activity at hand, the more important
communication and collaboration gets.

“Respect the complexity of software development, and don’t let estimation replace the

importance of empiricism itself.”

What do you think about this myth? Do you agree? What are your lessons learned?
Tips for Agile product roadmaps & product roadmap
examples

As a Product Owner, you are responsible for Product Backlog management,

stakeholder management and forecasting. Therefore, you will probably use a variety of
tools and techniques to track progress, manage expectations and keep people
informed. One of the tools that may come in handy for you is a product
roadmap. Applying product roadmaps effectively can be challenging however. The
concept of a product roadmap however, is that it is a high-level, strategic plan, that
describes the likely development of the product over the next period of time. The
roadmap should support the products' purpose and vision and it helps the Product
Owners to keep their stakeholders aligned. The roadmap also makes it easier to
coordinate the development of different products and it fosters transparency in order
to manage customer expectations.

In a lot of organizations, I see that Product Owners are focused mostly on developing
features and therefore, a lot of roadmaps are also dominated by features and
functionalities to be delivered. The disadvantage of focusing on features too much, is
that there are always too much features that would add value, therefore creating a lack
of focus on the vision and goals. By focusing on the features too much, the roadmap will
turn into an overloaded product backlog, instead of a high-level, strategic plan for the
products' future development.

In my everyday practice, I've seen a variety of product roadmaps that were used.
Although these three different roadmaps all have different pros and cons, I've seen all of
them add value for Product Owners in their daily work. Personally, I always use a
combination of these three roadmap practices. I mostly use the Storymap in the
beginning of a products' development, because I want to create insight for the
stakeholders in the products' features.
Goal Oriented product roadmap (GO product roadmap)

What I personally like a lot about the GO product roadmap is that it facilitates a lot of
focus on the goals you wan't to achieve as a Product Owner, much more than the actual
work to be done (the features). Although the GO product roadmap offers the possibility
of adding features, I like to start with the end goals in mind, and I believe every Product
Owner should do so. The GO product roadmap and focus on goals enables value
steering (steering on outcome) instead of steering on work packages (steering on
output). Since you are responsible for the product vision, strategy and roadmap as a
Product Owner, I believe this is a valuable asset of the GO product roadmap.

Another aspect of the GO product roadmap I like a lot is that it supports you in thinking
about the most valuable features that enable the achievement of your goals. Since Agile
is also about "Simplicity - maximizing the work not done" (Agile principle #10), I like the
concept that there is only a small amount of space in the model, to force you to think
about the top three most important features for a release. What I also like a lot, is that in
one glance, you can get an overview of you products' development over the next
upcoming releases, which comes in very handy to manage your stakeholders!
Depending on the organizations' context, I sometimes leave out the dates and release
name sections of the GO product roadmap. I do this since I've seen quite a lot of
stakeholders in the past, who saw the dates in the roadmap (which were forecasts from
my perspective) and they concluded that they would certainly receive the
functionality on the date that was in the roadmap. Since we're working in complex
environments which change and since people change their minds overtime, this didn't
always work out very well. Therefore, depending on the context, I sometimes use and
sometimes don't use the date and release sections, to stimulate interactions and to
prevent the wrong interpretations of the items on the roadmap. In these cases, I often
combine the GO product roadmap with the Now-Next-Later product roadmap.

Now-Next-Later product roadmap

The now-next-later product roadmap is a visualization I like a lot, because it's really
easy to understand for everyone. All stakeholders understand the concept of this model,
since it's easy to understand that you are working on the stuff in the "now" part, the
"next" part is what is coming up soon and the work to be done in the "later" part is
further away in time and still has to be prioritized.
The negative aspect of this roadmap from my perspective, is that it is focussed more
on the features, rather than the goals/objectives you would like to achieve as a Product
Owner. Besides that, the model doesn't offer much room for including KPI's, releases or
dates. Since dates and timelines are important information to stakeholders (in most of
the situations I have been in) this may be something you need to consider when
applying this type of roadmap. On the other hand, it may just as well be an advantage
that the now-next-later product roadmap doesn't include dates, since this offers you the
opportunity to interact with your stakeholders, instead of them reading the data from
your roadmap.As mentioned earlier, I often like to combine the now-next-later product
roadmap with the GO product roadmap, which adds more value for yourself and your
stakeholders.

Story map

The story map is a really nice type of roadmap that I often use in the beginning of new
projects or products. The story map is an excellent way to create a nice overview of all
the features you and your stakeholders can think of, which will be important to your
product. Although the idea is not to create an unlimited list of all the features and
functionalities that will likely be developed somewhere in the future, it does provide a
nice starting point to facilitate creative ideas for your product. What I like most about the
story map is that it provides an overview of all the user activities that need to be covered
by the system, which in turn enables you to create small and valuable user stories,
which can be developed and delivered incrementally and iteratively.

Another aspect I like a lot about the story map is that it starts with the user activities,
and thus taking a users' perspective on the product. I really like this concept,
since it helps you with brainstorming about the product from a users' perspective, after
all, we develop our products for our users and customers right?

The main downside of the story map that I've seen in practice is that it creates the
illusion that all the features for the product will be developed. Since we're being Agile, it
is not our goal to create a complete plan or breakdown for the product, so my advice is
to use the story map at the start of your new product development project, but also
make it very explicit to stakeholders that you will not neccesarily develop all of the stuff
in your story map. So manage these expectations well!

11 Tips for Agile Product Roadmaps

I hope these different roadmap types are useful for you, but remember: "Being Agile is
not about processes and tools but about individuals and interactions". Therefore,
and thanks a to Roman Pichler for offering some inspiration, I would like to share the
following 11 tips with you about creating Agile product roadmaps:

1. Start with your product vision (tip: use Roman's Product Vision board);
2. Describe and validate your product strategy;
3. Focus on goals and benefits, by creating a goal oriented product roadmap (or
one of the other types I've explained before);
4. Tell a coherent story about the likely growth of your product and don't oversell it;
5. Keep it simple! Resist the temptation to add too much details to your roadmap;
6. Actively collaborate with stakeholders to ensure buy-in;
7. Have the courage to say no, to prevent an overload of features in your roadmap;
 8. Think twice about adding timelines, dates or deadlines to your roadmap;
9. Make sure your roadmap is measurable, by adding measurable goals and KPI's;
10. Create a rough estimate for each feature (#people + required skills) to determine
the viability of a feature;
11. Review and adapt your product roadmap on a regular basis.
Thanks for reading, if you have any feedback to share please do, and good luck with
creating your product roadmaps!
Release planning and predictable delivery

Many organisations wrestle with the seeming incompatibility between agile and release
management and they struggle with release planning and predictable delivery.

Without working software, you cant build trust and you don't know when you will get the
next piece of working software.

Any software that you create is an organisational asset and decisions to cut quality
need to be reflected in your company accounts and as such those decisions need to
made by your executive leadership and should not be made by the Development Team.
Once you accept this, and quality becomes non-negotiable, your Development
Team can focus on creating shippable increments of working software. Once you have
shippable increments of working software you can then start to look with interest at the
progress being made on features and goals.

Without a regular cadence of delivery of working software any belief that you will get
working software is misguided at best. Professional Development Teams create working
software.

Release planning and predictable delivery

The incompatibility between predictable delivery and agility is fictitious (tweet this) and
while usually created by an organisation and structure that is unwilling to let go of the
old ways and embrace the tenets of agile it can also be the result of a Teams fervour to
divest themselves of all things that smack of prior planning. There is a lack of
understanding that agile and the path to agility is far more than just a change in the way
that you build software, it is a fundamental shift in the way that you run your business.
Much like the lean movement in manufacturing, companies that embraced it
wholeheartedly were the ones that ultimately see the competitive edge that it provides.
If one is unwilling to let go of the old ways then one can’t attain the value of the new.
This change will take hard work and courage as the fundamental transparency required
to inspect and adapt effectively is at odds with the measures of the past. The lack of
predictability of software development is the key to understanding the new model.

Why is software so unpredictable

All software development is product development. In lean manufacturing, we can

optimise the production of pre-developed products through the nature of its predictable
production. Each unit of work takes the same amount of materials and time to produce
so any changes that we make to the process, time, or materials can easily be qualifi ed
and the benefi t demonstrated. Manufacturing lives in the predictive world.

With software everything that we create takes its own amount of time: You can really
only know how long something took after it has been completed. Even in manufacturing
if you asked an engineer how long it would take to develop a new type of unit of work
they would not be able to tell you with any certainty. Once they have developed it
however they can tell you exactly how long it will take to make each one, and then
systematically optimise the process that you use to make it. In software development
we are always doing new product design, therefore, we have no certainty...and this
often results in chaos. Software lives in the empirical world.

All is not lost however as we can, by looking at our history of delivery for similar things,
make a pretty good forecast…

The best thing we can then do is to expend effort to make that forecast as accurate as
possible while accepting that more time spent planning does not necessarily affect the
accuracy of that forecast.
Figure: Diminishing returns from Agile Estimating – Estimation Approaches

Ultimately Software Development is a creative endeavour and has the same lack of
predictability that painting a picture, writing a book or making a movie has. Yet movies
get made all of the time. How can that possibly be! Well they have a Director (Product
Owner) that has a bunch of money and a plan for delivery, a Producer (Scrum Master)
to make sure that everyone has the skills, knowledge and assets available at the right
time and place and one or more Units (Development Teams) that have all of the skills
necessary to turn the Directors ideas into a working movie. They create Storyboards of
what they expect to create so that they can run it past the stakeholders and get
feedback. They take those storyboards to the Units who collaboratively work together
with the stunt, prop, lighting, camera, sound and wardrobe crews to get estimates and
costs and ultimately coordinating to create the movie. Sometimes they don’t know how
to do stuff, and just have to have a go and see what they get.

Making a movie is just like building software, you need a budget, you need a plan, and
you are trying to reach a ship date. And just like building software you have to make
money at the end of the day so that you can do it all over again.
Accept the lack of predictability

While I hope by now you understand that the lack of predictability is part of the nature of
building software, there are many things that we can do to lessen the impact of that
chaos. Indeed if you were to estimate all of the discreet things that you need to do to
achieve a goal (let us call them backlog items) in Small, Medium and Large what would
your standard deviation of actual hours be? I would wager that it is fairly large. So large
in fact that at least half of all mediums would be more accurately classified as Large.
But that reclassification can only be done with hindsight. This is indeed one of the
tenents of the No-Estimates movement, as really there are only three classifications of
size: trivial, fits in a Sprint, or too big to fit in a Sprint.

This difficulty in estimation is normal for organisations that move towards agility as the
transparency that it brings uncovers these sorts of problems. In order to increase the
accuracies of our forecasts, there are a number of simple activities that we can perform.
These activities, while easy to understand, are very hard to do as they require a culture
shift within your organisation as well as the courage of the participants to make them
work.

Focus on continuous quality

Most software lacks quality for the simple reason that you can not easily see the quality
in software like you could with a table or a painting. I am not talking about the quality of
the User Interface, but the quality under the covers; the quality of the code.

If you put developers under pressure to deliver they will continuously and increasingly

cut quality to meet deadlines.-Unknown (Tweet this)

A lack of quality of the code results in an increase in Technical Debt (or more accurately
an unhedged fund) which in turn results in two nasties. The first is the teams
increasingly have to spend more time struggling with the complexity of your software
rather than on new features. If you are still pushing your teams to deliver the same
feature level every year you are only encouraging them to cut more quality and thus
incurring more technical debt which becomes a vicious cycle. The second is an
increasing number of bugs found in production. Bugs found in production also directly
impact on the number of features that the team can deliver and any bug, no matter how
small, costs ten times as much to fix in production than it does in development.

The only way to handle technical debt is to stop creating it, and then pay a little back
each iteration. If however, you are so drowning in technical debt that you cant create
working software at the end of the iteration then:

1. Create a short measurable checklist that mirrors minimum releasable product

(Definition of Done)
2. Stop adding new features and make your product meet that checklist and
release your product
3. While you have an increment of working software (Sprint)
1. Work to create something of value (Increment)
1. Work towards a new goal while meeting the DOD (Sprint Goal)
2. Leave things better than you found them (Engineering Excellence)
2. Review that thing of value with your stakeholders (Sprint Review,
Backlog Adaption)
1. Get feedback on at least one new thing for stakeholders
2. Update the Backlog to reflect this new information
3. Reflect on how you worked with your entire team (Sprint
Retrospective, Kaizen)
1. Is quality increasing?
2. Is the DOD increasing?
3. What can we change to make things better?
4. Go to #1
You can call the activity that results from dropping out of the while loop of working
software to be a Scrumble; You need to stop piling more features on top of the features
that don’t work and fix things so that you can make new things. Ultimately professional
teams build software that works.

There are a number of strategies that can help you both stop creating and start paying
back technical-debt:

• Sufficient requirements – If your backlog has things in it that are too big or too
vague then your team will not really be able to understand them and this, in turn,
creates a multiplier for uncertainty. Follow the INVEST (Independent, Negotiable,
Valued, Estimable, Small, Testable ) model for every single thing that you ask the
team to deliver. If you invest in you backlog in this way you will fi nd it much
easier to deliver the contents and thus predict that delivery. This will require you
to spend a signifi cant amount of time in refi nement. Backlog refi nement is key to
facilitating a fl ow of actionable Backlog Items to your team.
• The Development Team chooses what they can deliver – this implies that the
Development Team can reject any item on the backlog that they do not
understand. If we accept that every Development Team is trying to do their best
to deliver for their Product Owner then the only reason to reject anything would
be if an item is too big or does not have enough detail to understand. These
Backlog Items can be put on the queue for refi nement and refi ned over the next
Sprint. Remember that there is no such thing as a rejected backlog item, only
actionable feedback and continuous improvement.
• Definition of Done (DoD) – Along with having suffi cient requirements the single
biggest blocker to predictability is a lack of common understanding of DONE.
Done for a Development Team should equal what it means to complete an item
with no further work required to ship it. If you cant ship working software then you
need to stop sprinting, Scrumble, and focus on getting your software into a shape
that can be delivered in a Sprint.
• Test First - Focus on Test First practices like TDD or ATDD to help you make
sure that not only did your engineers build what they expect, but that you
ultimately built what the customer expects.
• Fixed length iterations – If you have variable length iterations you can’t be sure
what you can do in a particular timeframe. How much decomposition do you
need to do to the backlog? How much can the team deliver in a single iteration?
You can’t be sure unless you have fi xed length iteration, and you reject the idea
of staggered iterations.
• No separate teams – This means no separate test teams, confi guration
management teams and defi nitely no separate maintenance teams. Its hard for
folks to grasp, especially with the recent focus on DevOps but if you have
separate teams then why would your Development Team, those best placed to
fi x any problems, care about the problems of other teams. The most successful
organisations at creating software have development teams that own the entire
application lifecycle (Amazon AWS | Visual Studio.)
• Manage dependencies - Managing dependencies is a hard task and my
advice would always be to minimise the number of dependencies that you
have. A Development Team should have all of the skills required to deliver what
you want at the quality level that you want. So if you need to have productionised
databases or scripting for production delivery then you might need a DBA or an
Operations administrator or two. This can be hard for many teams or
organisations but you will have far less success creating silos like Confi guration
Management or DevOps. Rather add those individuals that you need to the team.
However, if you have a dependency on a separate team, maybe you have an
application upon which all of your other applications depend, then you may need
another way. This is not a silo of types of individual skills, but of a domain and
that team just has something in their backlog upon which you are dependent. It is
up to the team's respective Product Owners to negotiate over when these things
get done.
 • Use a modern source control system - A modern source control system is
more than just code management, it should include all of the goodies talked
about in DevOps practices and beyond.
If you can, do them all, and many more…
Small batch delivery & big batch finance: how to speak the
language of forecasting

Your team has been trained and coached to deliver new chunks of software in a short
time frame. Those using Scrum will be able to deliver in a Sprint. Those using Kanban
will deliver as soon as their small feature is done. You’ve learned alternative ways of
estimating which don’t include time as a measurement. Maybe you’re using story points,
t-shirt sizes, or pills of vicodin to measure the complexity of your work. Delivery has
clearly improved, but you still get asked every December to estimate year-long
initiatives for annual budgeting meetings. Something doesn’t make sense and you’re
having a hard time explaining it to upper management. Ever hear of incremental
finance?

The Problem

Let’s look at the issue from another angle. When you take your car to a mechanic to get
new tires, you get a quote based on the set that fits your wheels, the brand and quality
you expect, and a time estimate for when it will be finished. If any of the variables don’t
line up with your needs, you’ll head toward a shop that can meet your expectations.
When you get your car back and pay for services rendered, there were likely few
surprises. The shop finished on-time, the cost was what you expected, and the brand of
tire you requested is on your car as you leave the shop. The people who finance your
projects are trying to make a similar decision regarding development initiatives. How
much quality can we get for what price? When will it be finished? What will we get for
that money? The difference here is that changing tires is a repeatable process. Auto
shops do this every day.

Software projects are complex with many unknowns about the technology, the people,
the problem, etc… The larger the project is, the exponentially more uncertain things
become. If you’re a software developer and think “I’ve done this before, I can estimate
it”, think again. Just look at a problem you solved a year ago. If you had to resolve the
problem using the same technology, would you write the code the same way? If you
said yes you’re lying to yourself.

I’ve never met a developer who enjoys their job that isn’t constantly improving the way
they write code. Writing software is more like writing poetry than changing tires. It can
always be written better, more concise, more readable and maintainable, even in the
same language with the same tools. Coding style changes over time as a developer
hones their craft. I remember a situation going through code I deemed too unreadable
to avoid rewriting, but hit a wall. Unable to decipher the code, I went off to find the
author to ask questions. After looking at the digital tags identifying the author, I realized I
had written the bad code just 6 months ago. This was proof to me that I would likely
never solve the same problem the same way twice.

On the delivery side we manage complexity by breaking large projects up into small and
manageable pieces that can be delivered quickly. This technique is why we are agile
and can respond quickly to change. If a mistake is made or the customer doesn’t like
what was made, it’s far easier to change direction if we didn’t go too far on the wrong
path before having something to deliver.

More on managing complexity

To understand why you would consider an "incremental finance" approach, let’s look at
a couple other examples of complex systems that your finance people and senior
management will better understand: The stock market and hurricanes.
No one will guarantee estimates of the behavior of these systems in the long-term. No
one legally knows what the stock price of their favorite tech company will be in one-
year’s time. No meteorologist really knows where hurricane johnny is going to be in a
week.

The best tools we have involve creating a forecast, inspecting at a regular cadence and
updating the forecast based on new information. Let’s take a look at a financial forecast:

Figure 1 - S&P 500 2012 forecast

At the end of 2011 this graph represented the best information available to forecast
what 2012 would look like. Notice the wide cone... its representing a large range of
possibilities that could occur by the end of 2012. Also notice none of them involve the
S&P 500 hitting 1000 or 2000. The range of possibilities narrows as you are nearer to
the present. As it turns out, the S&P closed at 1257.60 on December 30th 2012. Just
north of the bottom end of the cone. For passive investors, applying a dollar-cost-
averaging tactic can help smooth out the rocky ups and downs of when you purchase
and keep ROI favorable. This is an incremental finance technique.

Hurricane forecasting is very similar. This is a forecast made for Irene

Figure 2 - Forecasted path of Hurricane Irene

While the actual path of Irene was somewhat different than the original forecast, it
remained within the forecast the whole time.
Figure 3 - Actual path of Hurricane Irene

To understand forecasting complex projects, you need to understand the cone of

uncertainty. Its an easy-to-digest model representing the variance in estimates you’ll
find in a complex system. When you are close to done, estimates vary less. When you
are much further from done, estimates vary much more and it’s not a linear relationship.
Using this model, you’ll want to be closer to done when you estimate. The closer you
get to done with any work, the more likely you’ll be right in estimates about when it will
be finished. The further you are, the worse. Still feel comfortable giving an estimate to
that e-commerce website rewrite?

Figure 4 - The cone of uncertainty

Explaining "incremental finance" to senior leaders

It’s important to discuss this with your senior leadership and to explain the complex
nature of software development. Show them that long-range estimates include
exponentially increasing variance as predicted by the cone of uncertainty. The key to
success is breaking up large initiatives into smaller deliverable and valuable pieces...
and fund those. If you can get your initiatives down to 3-month, completely finished
projects, you’d be on the right track to better estimates and better funding decisions.

Projects often get batched larger and larger. Resist that urge and encourage your senior
leaders to do the same. This technique is not that different than earnings forecasts wall
street analysts produce and their follow up examination of true earnings public
companies report quarterly.

I strongly recommend you employ an empirical process to investing in your company’s

initiatives through with incremental finance and break the large batch project funding
cycle that prevents true organizational agility.
Scrum Myths: There is No Planning in Scrum

A recurring Scrum myth I see in my training and coaching is that there is no planning in
Scrum. Unfortunately, this myth can lead to two negative consequences.

1. The people in organizations responsible for budgets, product management,

sales, and marketing may be unwilling to try Scrum.

2. Scrum Teams may not be effective in their use of Scrum.

The reality is we plan A LOT in Scrum.

We just plan differently to optimize effectiveness.

In Scrum, we emphasize the activity of planning over the plan itself.

We know the plan is going to change. And this mindset honors the agile value of
adapting to change over following a plan.

In Scrum, the activity of planning is collaborative.

The Sprint starts with Sprint Planning, and the entire Scrum Team participates. This is a
collaborative negotiation to determine a valuable outcome the team wants to achieve.
The Development Team creates the Sprint Backlog, identifying what will be delivered
and a loose plan for meeting that valuable outcome.

The Daily Scrum is a collaborative planning session for the Development Team to
inspect progress and adapt the plan to meet the Sprint Goal.

The Sprint Review is a collaborative session to gather input needed to help plan the
next Sprint.

The Sprint Retrospective is a collaborative session to enable and plan for continuous
improvement.

In Scrum, the people doing the work own the plan.

The Development Team owns the Sprint Backlog. They create it, and they can adapt it.
This ownership means the plan will reflect the current reality, incorporating input from
the most knowledgeable people. For release-level planning or forecasting, the entire
Scrum Team owns this. It requires a collaboration because of the distinct
accountabilities of the Scrum Roles.

Planning in Scrum is part of every Event.

In every Event, we are both inspecting and adapting. That is the essence of planning.
If we don’t see the adaptation happen during a Scrum Event, it is time to revisit the
Scrum Team’s understanding of the purpose of the Events.

Furthermore, the Scrum Framework is just a framework. It encourages Scrum Teams to

apply complementary practices where relevant to further assist with planning, including
release planning and product backlog refinement techniques. Development Team
members choose how to do their work, and they may have planning discussions
throughout the Sprint.

In Scrum, the way planning is done reduces waste.

A plan is out of date a minute after you discuss it. Therefore, we keep the plan
lightweight and make it easy to update the plan. Some ways that we reduce waste
related to planning include:

• We minimize time spent analyzing things that may never happen. The
further something is in the future or down the ordered list of priorities, the less
time we spend trying to gather details.

• We minimize time spent analyzing to an impossible level of accuracy. There

is a point where our gains in accuracy no longer outweigh the time spent to get
there. We accept that the complexity and unpredictable nature of software
development make it impossible to have a perfect plan.

• We incorporate meaningful feedback every time we plan. By doing the work,

by building software, we learn the most valuable information for helping us adapt
our plans.

In Scrum, we still recognize the inherent unpredictability in complex software

development.
By being honest about this, we can be transparent about the current progress and likely
completion dates. This helps us build trust. This enables us use an empirical process to
enable business agility, to make difficult decisions, and to do professional work.

In summary, planning effectively is an essential part of Scrum. I have experience

working as both a Project Management Professional (PMP) in the traditional delivery
environment as well as working as a Professional Scrum Master (PSM) and Coach in
an agile delivery environment. I argue that when we do Scrum well, planning in Scrum is
more effective.
Calling All Industries: Your Process is Failing You

What the Software Industry Can Teach Everyone Else About Curbing Failure and
Delivering Value

Not to be blunt, but this project you’re working on, it is likely to fail. I’m sorry to break it
to you, but it’s probably not going to turn out. It is beyond debate I’m afraid; business
projects are prone to failure – particularly large and complex projects. There is some
irony in that, no? The more you hope to achieve, the more likely you are to be
unsuccessful. Cost related to failed projects on the national GDP and our collective
productivity is massive. This cost doesn’t even include the careers detoured or jobs lost
on the fiery embers of failed projects.

Again, excuse my frankness on this matter, but us IT/software/tech folks at this point are
pretty well versed in the statistics. We know first-hand how big, expensive projects can
fail. You’ve probably seen it; our reliance on technology in every aspect of our lives
brings these IT failures to the forefront. But it is inaccurate to believe that failed projects
are limited to technology. This dilemma is cross-cutting and affects your business just as
much as it affects Uber, Facebook, and Youtube. Just to air everyone’s laundry without
prejudice, here is a list of infamous non-software project failures:

• The French Panama Canal where the French attempted to construct a canal in
Panama under the impression it would be easier than it was to complete the
 Suez Canal. The effort failed, and it cost $287 million. Two hundred and eighty-
seven million dollars in the 1800s! Also, sadly more than 20,000 people died
during the effort.
• Marble Hill Nuclear Power Plant in Indiana was abandoned unfinished in 1984
after spending $2.5 billion on the project.
• The Berlin Brandenburg Airport took 15 years to plan, began construction in 2006
and was initially expected to open on Oct 30, 2011. Now, seven and a half years
later, the new scheduled opening is in 2020, and the current cost of the project is
close to 50% above the approved budget of 5.4 billion euros.
• The Rio de Janeiro Olympics which were plagued by inhospitable living
conditions, inadequate gaming facilities, political and social unrest, and a threat
of a Zika outbreak.
This is just a short list of failed projects. The actual list, of course, is too long to enter
here. You don’t want to end up on this list! But, alas, it is true that fewer than a third of
all business projects are completed on time and on budget. And the failure rate of
projects with budgets over 1 million dollars is50 percent higher than the failure rate of
projects below $350,000.

Have you been part of a project that either was not completed at all, went dramatically
over budget, or finished with a product that no one wanted? It’s a terrible and
disheartening position to find yourself. Why does this happen? How do we fix it? Well,
the technology industry has been working to address the issue by looking at the
processes we use to complete projects.

YOUR PROCESS IS FAILING YOU

In software, Waterfall has been the dominant product development practice for the past
half-century. Many professionals and organizations outside of technology use Waterfall
techniques to complete projects without knowing it is Waterfall. It’s just the process.
Waterfall is a methodology for developing products that organizes work into large
sequential steps. The process typically flows in one direction, which is forward – thus
the term Waterfall. For example, the steps could be design, implementation, testing,
deployment, and release.

The sequential approach of Waterfall means taking big steps instead of a more iterative
and incremental approach. Big steps are more likely to fail. For one reason, it requires
you to predict outcomes sometimes months or years ahead of time. Surely, predicting
the future is a challenge; bad predictions lead to bad products, and bad products lead to
failed projects.

With deployment and release as the final steps of the Waterfall sequence, feedback
from stakeholders is limited. You primarily get feedback at the beginning and end of a
product development cycle. In between, there could be months, even years. You see
the problem here: this lack of feedback over a sizable period leads to a disconnect from
current customer requirements and causes you to deliver a product of low business
value.

In many ways, conventional project management solidifies the shortcomings of

Waterfall. Project management is almost exclusively about delivering on time and
managing resources versus delivery of a quality product that delights customers. It is
about “just getting it done” on time. I bet we all, no matter what industry, have been in
the terrible position operating under that slogan.

Waterfall was initially designed to create software much in the same way Henry Ford
constructed automobiles. Given that, and these sorts of statistics (50% failure on large
projects!), it is past time to reevaluate Waterfall as the de facto solution. Can you afford
to continue in this manner? Failed projects help competitors, waste resources that are
better spent on successful projects, demoralize employees, and harm your brand.

INCORPORATING A SCRUM FRAMEWORK TO CURB FAILURE AND DELIVER

VALUE

So, how is the software and technology industry moving away from failed projects that
“just get done,” toward curating a methodology for success and creating valuable
products for their customers? Agile, most notably, Scrum has been the most impactful in
inciting change in this direction.

Scrum is a process framework for resolving complex problems iteratively and

incrementally to a create a high-value solution that elates customers. Scrum directly
addresses many of the shortcomings of Waterfall with project management.

Scrum is:
 • Empirical instead of predictive
• Iterative instead of sequential
• Concentrated on gathering continuous feedback instead of gathering in stages
• Value-focused instead of deadline-focused
• Self-organizing instead of control and command
EMPIRICAL: BASE YOUR DECISIONS AND PROCEDURES ON EXPERIENCE AND

EXPERIMENT

What are you doing on September 21, 2021? Where were you yesterday? If the first
question is easier for you to answer, go ahead and skip ahead to the module on magical
people. For the rest of us, we already discussed how difficult it is to predict the future.
But we can look backward with certainty. In Scrum, decisions are made based on
experiment and experience. This is what it means to be empirical. For practical reasons,
product development often requires a planning horizon. If so needed, keep the planning
horizon to a limited amount of time.

ITERATIVE: ORGANIZE YOUR WORK INTO SMALLER STEPS

Scrum is iterative and incremental; not sequential. Instead of planning work in large
stages, such as design and implementation, organize work in small steps (we call them
sprints) where there is the opportunity for continuous feedback – especially stakeholder
feedback. Taking small steps will make you nimble where you can adjust to market
conditions and focus on delivering a product of high value. Typically in Scrum, sprints
last one or four weeks and include a lot of broken down tasks. By the end of the sprint,
you should have something to release.

CONTINUOUS FEEDBACK: STAY ALIGNED WITH CUSTOMERS AND

STAKEHOLDERS
An important part of Scrum is the “daily Scrum.” This is short meeting (15 min), usually
at the beginning of the day that allows each member of the project team to give a quick
update on their status. The daily Scrum also helps frame the work of the upcoming day.
Another event in Scrum is the Sprint Review. At the end of your one to four-week project
sprint, your team gets together for an informal meeting. In the Sprint Review, your team
shows what they have accomplished during the sprint to stakeholders of the project.

CUSTOMER VALUE: THIS IS YOUR PRIMARY FOCUS

Scrum’s focus is on delivering products of high-value. The goal should be more than
simply getting a product or project completed. You want to deliver the most competitive
product possible based on customer requirements. This requires continuous feedback
and integration of the customer into the process – both of which are cornerstones of
Scrum.

SELF-ORGANIZED: EMPOWER TEAM MEMBERS TO SELECT AND HOLD

RESPONSIBILITY FOR THEIR WORK

Scrum development teams are self-organizing. A development team is anyone that

contributes to or helps complete a product or project. No one tells the development
team what to do. They estimate and select their work. This approach empowers
development teams to take full responsibility for their work. When someone (i.e., the
Project Manager) tells them what to do, they are much less accountable for their work.
This does not only apply to software development teams but your team too. Empowered
teams are much more successful.

STOP WASTING TIME AND MONEY AND DELIVER VALUABLE PRODUCTS

There is only one reason the continue with a Waterfall method – low expectation.
Stakeholders will be pleasantly surprised when you occasionally finish a project on time
and on budget working with a Waterfall process. I suggest a different approach.
Captivate customers with successful products and instill a culture of high expectation
and value. Instead of wasting resources on the occasional successful projects, start
incorporating Scrum into your process today. Scrum has proven to be hyper-effective for
us, as well as, other IT organizations. We intend to share this practice with you whether
you’re an educational or financial institution; a marketing or production team; or
interested in using Scrum to help manage your business. This article is the beginning of
a series of posts related to Scrum and Agile for Non-software projects, so stay tuned for
more information, tips, and tactics to introduce the Scrum Framework into your
organization. Contact us, or comment below with questions or requests for more
information as we go along.
The Art of Product Backlog Refinement

A common question I hear in Scrum training courses and in coaching sessions is, “how
much Product Backlog refinement should we do and how much detail should be in the
Product Backlog?”

First, let’s look at the Scrum Guide.

Product Backlog Refinement

According to the Scrum Guide, Product Backlog refinement is the act of adding detail,
estimates, and order to items in the Product Backlog. But Scrum doesn’t prescribe how
you do it, and for good reason.

Refinement is an ongoing process. It never stops because requirements and

opportunities never stop changing. Detailing everything up front would create waste
and also delay the delivery of value.

Different products and different teams will have unique needs in terms of
frequency, techniques, and level of detail.

Even the same Scrum Team working on the same product will need to evolve how they
do Product Backlog refinement over time to fit new situations. Scrum Teams needs to
figure out what works for them. So how do they do that?

Self-organization and empiricism.

Apply the Goldilocks Principle to help a team experiment and find what works best for
them through inspection and adaptation.

The Goldilocks Principle and Product Backlog Refinement

The Goldilocks Principle is about finding what is “just right” for your team.

The goal is to balance gaining enough benefits from the activity while minimizing
the potential waste.

Let’s first look at the 6 benefits of Product Backlog refinement:

1. Increase transparency
2. Clarify value
3. Break things into consumable pieces
4. Reduce dependencies
5. Forecasting
6. Incorporate learning
Now let’s dive deeper into each of these to see how we can apply the Goldilocks
Principle. I’m going to give you a couple of starter questions in each of these 6 benefit
areas to help your team figure out if it’s too hot, too cold, or just right.

#1 – Increase Transparency

The Product Backlog is an artifact that helps provide transparency. It is the “single
source of truth” for what is planned in the product. Adding details increases
transparency to what you plan to deliver, as well as your progress.

Goldilocks Questions

• How well do stakeholders and the Scrum Team understand what is planned for
the product?
• How frequently are the interested stakeholders surprised by what was delivered?
#2 – Clarify Value
When you clarify the details around value, the outcomes you are trying to achieve with
the Product Backlog Item (PBI) are more clear. Why do you want this? What is the
user benefit? What is the business benefit?

This helps the Development Team build the right thing to meet the need. This can
affect what is requested, the estimate, and the order as the Product Owner and
Development Team figure out what is actually needed. This conversation creates a
shared understanding.

Goldilocks Questions

• How often do you discover during a Sprint that there is not a shared
understanding of the business need or what you are building to meet it?
• How frequently do you discover in a Sprint Review or after a release that a PBI
does not meet the user or business need?
#3 – Break Things into Consumable Pieces

You want PBIs to be small enough that a Development Team can complete more than
one in a Sprint. Having more than one PBI in a Sprint gives the team some flexibility to
meet a Sprint Goal and deliver a “Done” Increment.

Goldilocks Questions

• How often are you not delivering a “Done” Increment? How often are you not
meeting a Sprint Goal?
• When is this attributed to discovering mid-Sprint that PBIs are much bigger than
you thought or not sliced thin enough?
#4 – Reduce Dependencies

Dependencies often turn into impediments and can grind a team to a halt. While
you may not avoid them all, you should try to reduce them where possible. This is
especially important for dependencies outside the Scrum Team. You can slice and split
the PBIs in different ways. You can re-order, or you can collaborate with other teams to
help resolve the dependency in advance. There are many options, and at the very
least, you want the dependencies to be transparent.

Goldilocks Questions

• How often do you discover dependencies during a Sprint that jeopardize the
Sprint Goal?
• How long do PBIs in a Sprint stay “blocked” by dependencies?
• When do you have to re-order the Product Backlog to account for dependencies?
And how much of an impact does this have on the Product Owner’s ability to
optimize value?
#5 – Forecasting

A refined Product Backlog combined with historical information about the Scrum Team’s
ability to deliver working product helps you forecast. Some products need to forecast
several Sprints into the future to help communicate release expectations with
stakeholders. Other products will not have a need to do forecasting beyond the current
Sprint. Most products fall somewhere along this spectrum.

Related to forecasting, you also may need a refined Product Backlog in order to get
funding. Scrum does not forbid up-front planning. Scrum simply says to consider
your effort to do so, the potential waste, and the fact that you cannot perfectly predict
the future in a complex domain no matter how much analysis you do.

Goldilocks Questions

• How much lead time is necessary for users, customers, and other stakeholders
to implement a new feature or function? What is the impact if they have less lead
time?
 • How much detail do users, customers, and other stakeholders need in release
forecasts? What is the impact if they have less detail?
#6 – Incorporate Learning

Empiricism is about incorporating the learning you gain as you build the product, as
you better understand how to realize the product vision, as you see changes happening
in your environment.

Goldilocks Questions

• How are you adapting the Product Backlog to reflect new learning about the
product’s evolving capabilities and how users are responding to the changes?
• What opportunities have been missed? What prevented you from responding
sooner?
Pulling It All Together

You’ve discussed the Goldilocks questions about refinement benefits with the Scrum
Team. (Sprint Retrospectives are a great opportunity to regularly have these
conversations.) Now it’s time for the Scrum Team to decide how to adapt their process
for Product Backlog refinement. There is a reason these are open questions and not
simple yes/ no questions.

You are looking for balance, or that “just right” spot. You want to achieve enough of the
benefits of refinement while minimizing your waste.

With the information gained from exploring 1-6, the Scrum Team can now consider
these questionswith the balance of benefits and waste in mind.

Goldilocks Questions
• How frequently do you want to do refinement? And how much time do
you want to spend detailing the Product Backlog?
• Who do you want to be involved in refinement? What knowledge and
perspectives are needed? How will you enable shared understanding?
• How much of your Product Backlog do you want to be “Ready” before a Sprint?
What does “Ready” mean to you?
• How do you want to communicate important details about PBIs? What methods
are working well and what methods are not?
• How will you ensure you can see the whole and not get bogged down in details?
Myth 14: Refinement is a required meeting for the entire
Scrum Team

Myth: Refinement is a required meeting for the entire Scrum Team

Is “Product Backlog refinement” a recurring event in your Sprint schedule, happening on

a fixed day during the Sprint? Is it something that developers slog to with lead in their
shoes, mentally preparing themselves for another multi-hour required meeting where a
few people talk and most people (pretend to) listen? If so, then this post is for you.

Product Backlog refinement is certainly an essential part of the Scrum Framework. But
more often than not, it takes the form of a team passively sitting around a meeting table
while a subset of the team discusses upcoming items in excruciating detail. Things are
not helped by having to wait for that one member with the keyboard to enter everything
in JIRA. When doing Product Backlog refinement like this, it is understandable that
teams try to spend as little time on it as possible — which is one of the key reasons
holding Scrum Teams back from becoming truly awesome.

In this post, we bust a myth that is at the heart of why refinement feels like a chore to
many Scrum Teams: the belief that ‘Product Backlog refinement’ should be done as one
or more required ‘meetings’ that must be attended by everyone in the team. We also
offer some alternative approaches that fit more naturally with the flow of development.

What does the Scrum Guide say?

The Scrum Guide describes Product Backlog refinement as the act of adding detail,
estimates and order items in the Product Backlog. It goes on to describe that this is an
ongoing collaboration between the Product Owner and the Development Team and that
the Scrum Team as a whole decides how and when to do this.
The Scrum Guide prescribes five required, time-boxed events that happen on
prescribed moments during the Sprint: the Sprint Planning at the start of the Sprint to
select what the team will work on, the Daily Scrum to synchronize work every 24 hours,
and the Sprint Review and the Sprint Retrospective at the end of the Sprint to inspect
the results from the Sprint and the way the team collaborated during the Sprint,
respectively. The fifth event is the Sprint itself.

So the Scrum Guide is quite clear; refinement is not an event in Scrum. This may
appear like mere wordplay. But it does have a significant impact on how it is done in the
real world. The guide emphasizes that Product Backlog Refinement is something that
Development Teams do as a natural part of development. It is not something that
necessarily happens at a fixed moment during the Sprint where the entire Scrum Team
has to attend. Yet, this subtle distinction is sometimes lost and is one of the reasons
why Product Backlog Refinement has become a chore for many Scrum Teams.

Before jumping into alternatives, lets first explore the purpose of Product Backlog
refinement in a bit more detail.

The purpose of Product Backlog refinement in Scrum

Scrum is built on the observation that product development is complex. Because of this
complexity, better insights and ideas will emerge as we’re doing the work. This means
that even the near future is difficult to predict. Scrum provides a lightweight framework
for allowing this learning to happen as quickly as possible without losing the focus
needed for solving complex problems.

“Scrum provides a lightweight framework for allowing learning to happen as quickly as

possible without losing the focus needed for solving complex problems.”

The Product Backlog captures all the work needed for the product that we know of at
this time. Some items will be small and clear enough to complete within a single Sprint.
While other items will be too big, too unclear or both. To maximize what we can learn
(e.g. from feedback from stakeholders and by simply doing the work) and to reduce the
risk of building the wrong product, we want to break down and clarify items to the point
where we are fairly confident that we can complete them within a Sprint.

It may be tempting to go ahead and break down all the work on the Product Backlog to
make it fit within a Sprint. But a much better use of our time is to break down and clarify
only those items that we’re about to start work on (say next Sprint or one soon after).
The time spent on items further down the Product Backlog is largely wasted as we are
bound to learn things that change our views on how to implement them or make them
irrelevant altogether.
As an activity, Product Backlog refinement has the following purposes in Scrum:

• Clarifying items on the Product Backlog that are too unclear to start work on. This
is preferably done directly with the people you’re building the items for (the
stakeholders);
• Breaking down items that are too big to pull into a Sprint (which generally also
means that they’re too unclear);
• Re-ordering the Product Backlog as needed to make the upcoming Sprints as
smooth and valuable as possible;
• Adding or removing items from the Product Backlog as new insights emerge;
• Estimating the effort involved in implementing particular items. This does not
have to be as ‘formal’ as assigning story points (an optional practice in Scrum), T-
shirt sizes or whatever sizing technique you use. A gut feeling (“Yeah, we know
well enough what needs to be done and it feels doable in a Sprint”) is fine too;
Items on a Product Backlog are essentially reminders of “conversations that we will
need to have in the future”. Refinement is simply the ongoing process of having those
conversations. Sometimes this means talking with stakeholders about some item that
may be part of the next Sprint, while at other times it can be an item that is part of the
current Sprint. But instead of this series of conversations that naturally flow from
development, for too many teams it has taken the form of a formalized meeting taking
place (only) during a Sprint.

“Items on a Product Backlog are essentially reminders of conversations that we will

need to have in the future.”

Try the converge-diverge pattern

For many organizations, ‘meetings’ have become the de-facto standard to integrate and
exchange information within teams and make decisions. In a meeting, we bring as many
minds into the room as we can for a given amount of time to achieve a purpose. The
assumption here is that this is the best (or even the only) way to tap into the wisdom
and creativity of teams and to share knowledge. However:

• Not all activities related to refinement are ideally suited to do with the whole
team. The breaking down or clarification of items, for example, can be done by
varying subgroups in the team that then converge back to the team;
• Breaking down items is often a complex activity requiring significant creativity
and time to think things through. As most developers will recognize, refinement
can also take place during lunch conversations or cycling to work. Meetings are
often not the best environment to do this kind of heavy mental weight-lifting;
• There is a natural flow to development during a Sprint. We want to break this flow
as infrequently as possible, which is also why the Scrum Guide prescribes only
four required events during a Sprint. This minimizes the need for other whole-
team events;
• Sitting down around a conference table in a meeting room is not a very engaging
way of doing complex work;
We believe that many teams can benefit from a Diverge-Converge Pattern. As a team,
decide which items need to be clarified or broken down and who wants/needs to be
involved. The smaller groups then do this work during the Sprint or during
‘Breakouts’ (Diverge) and share their results with the Scrum Team at a later moment
during the Sprint to decide on next steps together (Converge). Other activities, like
estimation or re-ordering of the Product Backlog can then be done together based on
what was learned during refinement. Multiple Diverge-Converge cycles can happen
during a Sprint, depending on the complexity of what needs to be refined.

“We believe that many teams can benefit from a Diverge-Converge Pattern to

refinement.”

Whatever you do, make sure that refinement remains a collective effort of the team.
Although not everyone has to do it at the same time, everyone should be involved in
it. Having only the analysts or lead developers do refinement is a powerful anti-
pattern as it fails to tap into the wisdom of the entire team.

More tips to refine work differently

Rather than spending hours around a table, refinement is an excellent opportunity for
the Scrum Master to help the team find different ways to do this:

• Invite the Scrum Team to form smaller groups that take responsibility for the
refinement of particular items during the upcoming Sprint. Let them decide how
and when to do this, collaborating with the Product Owner and stakeholders
where necessary. Schedule moments where the pairs share their ideas and
insights with the Scrum Team and gather feedback;
• Don’t use tools (like JIRA) during refinement. It’s a huge drain of energy and
creativity if people have to wait for that one person with the keyboard to complete
typing in a new item. Instead, refine work with post-its or drawings and ask the
team to enter it into the tool afterwards. If you really need to use tools during
 refinement, make sure that everyone has access to it and can work in it
collaboratively;
• Combine Liberating Structures or other facilitation techniques to turn boring
refinement sessions into highly interactive sessions where everyone is fully
engaged. If you’re breaking down challenging items, invite people to draw the
problem. Use 1–2–4-ALL to quickly identify potential strategies or Troika
Consulting to give and get help. Use supporting material, like our sheet with 10
potential strategies for breaking down work;
• Invite stakeholders to participate in refinement where needed. In order to clarify
upcoming work and to build the right product, you will certainly need their
perspective and knowledge;
• Invite team members to decide for themselves if they want to join meetings
where the purpose is to break down specific items. Have them determine if they
can contribute something to the conversation. If this results in nobody showing
up, you have a good topic for the upcoming Sprint Retrospective;
• Experiment with what works for your team. For some teams, doing refinement
together is the best way. For others, the above solutions may be more helpful. It
depends on the size and maturity of the team and its members and the
complexity of the domain;
• When using a physical Product Backlog you can easily add information that is
relevant for refinement. For example: add stickers with a question mark to items
that need clarification. Write exclamation marks on items that might become a
risk or are important items to refine.
• Instead of doing refinement during a meeting, go for a walk outside and use your
walk to break down work with your team or subgroup;
Closing

In this post we busted the myth that Product Backlog refinement should be done as one
or more required ‘meetings’ that must be attended by everyone in the team. We clarified
the purpose of refinement in Scrum, offered alternative approaches to do refinement
and provided some tips to increase the effectiveness.
If your backlog is not refined then you are doing it wrong

Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try
to work on things that they don’t understand correctly. However, if you get to the Sprint
Planning Event and your backlog is not ready, then you are doing it wrong. If what you
build is not of good quality then you should read about Defenition of Done.

If you get to the Sprint Planning event and your Product Backlog Items for the next
Sprint are not already of a size that can fit into the Sprint and fully understood by the
Development Team, then you are doing it wrong. You are heading for the rocks from the
start, and you have no map of the shallows to prevent it.

Although the Scrum Guide does not define Refinement as an Event, you should be
doing it. You can come up with your Refinement event(s), or refine ad-hoc. Whatever
you chose there is a simple measure of success. If your Development Team looks at
something within the next 2 Sprints on the backlog and they don’t understand it, then
you have work to do.
If you find that you can't quite get things to fit and have to stagger iterations, or you are
just not able to deliver at all, then a lack of refinement is usually at fault.

What does ready mean for a Product Backlog?

If the Development Team does not understand the things that they are being asked to
do how could they possibly agree that the items can fit in a Sprint? You will often find
teams that don’t do refinement confused as to why they cant get everything done in a
Sprint. While we accept that in an empirical process like Scrum that we, know less up
front than we discover as we go, merely taking a guess and hoping for the best is
decidedly unprofessional.

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

-ScrumGuides.org

While we don’t need a definition of ready, we do need a working agreement between

the Product Owner and the Development Team. If you are following Scrum, then the
Development Team are the ones selecting for the Sprint, and they are the only ones that
can decide what they can do. The Development Team should be empowered to refuse
to take items from the backlog that either they do not understand, or are too big to be
completed in a single sprint. In general, I would expect that a team take at least ten
items into their Sprint, so they need to be sized appropriately.

Ready Backlog just means that the Development Team can select it with confidence.

How do you refine your backlog?

Refinement is not an explicit event in the Scrum Guide because it is something that can
be different depending on the Product, Domain, or Technology. If you were to ask how
much refinement you should do then the answer is "as much as you need and no
more". Too much Refinement is waste, as it too little.

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

-Scrum Guide

In the Scrum Guide there is the guide that it usually takes not more than 10% of a
Development Teams time, and for a two-week sprint, this is reflective of a whole day per
Development Team member. 10% may seem like a lot, but not only is it necessary it is a
maximum guide and not a minimum. I have found that many teams that were not doing
refinement in the past may need considerably more time to get their backlog into some
semblance of order. Once it is in order, you are only maintaining a rolling two Sprint
projection of what you might achieve.

I usually run at least the first refinement as a guided workshop. Run one before a Sprint
Planning and most teams will see the value by the end of the next Sprint. For the
Workshop, I get the Scrum Team (Product Owner, Development Team, & Scrum Master)
into a room with any necessary subject matter experts and we merely open the existing
backlog. Start at the top and ask the Product Owner if this is the next most important
thing? If not, find something that is. Then have the Product Owner read and explain it.
Any time the PO deviates from the text that is in the Backlog Item, or adds more
information, stop and have someone add that info to the Backlog Item. Ask the
Development Team to estimate the item (will or will not fit is fine too as in #noestimates),
"Does this look like it can fit with nine other friends into a single Sprint?". If the answer is
no, then you get to work breaking it down, reordering in the Product Backlog, and start
refining again. You continue this process until the Development Team agrees that there
is enough backlog refined for the next 2 Sprints.

This enables your Product Owner to be able to plan future releases and your
Development Team to create an execution plan for the current one.

How do you monitor your refinement effectiveness?

During the Sprint Planning event, your Development Team should be able to quickly
select a least 10 Product Backlog Items that go towards the chosen Sprint Goal and
agree that they fit. If you can do this, and most of the time you get most (not all) of the
Items delivered, then you are probably doing enough refinement. If you can't, then you
need to focus a little more on Refinement and making your Product Backlog Ready.

If at your Sprint Review the Product Owner is always wanting to reject that Backlog
Items are complete then there is unlikely to be enough refinement for the Development
Team to understand what they are expected to do.
Getting to Done: Balancing Emergence and Delivery

In a previous post describing challenges to creating a done Increment, I identified too

much change during the Sprint as one of those challenges. The Manifesto for Agile
Software Development talks about responding to change over following a plan. It also
says that the best architectures, requirements, and designs emerge from self-organizing
teams.

So how do we respond to change and allow emergence while still delivering

something of value that works?

First lets define delivery and emergence. In Scrum, delivery is releasable software by
the end of a Sprint. Because we are dealing with complex work, we do not know
everything about what is needed and how to deliver it before we start working. This is
where the concept of emergence comes in.

Emergence implies that all solutions to all problems will become clear as we
work, not simply by talking about them. Essentially, we need the ability to learn for
experience and respond to what we are learning. This could mean fine-tuning our
direction, changing course altogether, or continuing forward as our assumptions are
validated.

Balancing emergence and delivery are challenging. There is no formula. Teams have
to figure out what will work in their situation.

So let me provide some guidance on where to start looking if it feels like there is too
much change happening, and this is affecting the ability to deliver of a Done Increment.

3 Challenges Balancing Emergence and Delivery

1 - New work is being assigned to the Development Team.

The Development Team should be focused on the Sprint Goal and using the Sprint
Backlog to visualize progress towards achieving it. Nobody should be adding work to
the Sprint Backlog except the Development Team. Remember that the Sprint Goal
helps the team stay focused and provides flexibility as work emerges. If someone is
giving the Development Team other work to do, then we have broken focus, and we
have undermined team ownership.

Here are a few ideas for handling emerging priorities not in line with the Sprint
Goal.

•
• A Scrum Master can help protect the Scrum Team from outside
distractions by teaching them the rules of Scrum, by helping them understand
their accountability, by helping them understand what decisions they own. This
includes teaching the Product Owner to prioritize new requests in the Product
Backlog rather than try to push them into the current Sprint. This includes
educating stakeholders about Scrum. This could also mean leveraging
management.
•
• It can be hard to say no to the "shoulder taps," but team members can help by
holding each other accountable. If someone brings up something they are
working on that isn't on the Sprint Backlog (or they try to add it to the Sprint
Backlog), it is the team's responsibility to question it. This is a hugely supportive
thing to do for team members. Everyone struggles to say "no." Having support
from your team when you need to say "not now" is helpful.
•
 • If new work emerges during the Sprint, the Development Team and the
Product Owner should negotiate. If something is going to come in, it is very
likely that something else must come out. Remember that our Sprint Goal should
not be changed during the Sprint.

2 - Poor Product Backlog refinement causes the "what" to grow during the Sprint.

Product Backlogs are not meant to be detailed requirements contracts. We expect

details to emerge during the Sprint, and there may be a few surprises periodically.
However, we may see an overwhelming amount of details emerge during a Sprint. The
Sprint Goal becomes unachievable, or the Scrum Team spends so much time analyzing
and negotiating that little time is available for actually delivering the Increment. This
could be a sign that we are not doing effective Product Backlog refinement.

•
• Consider having the full Scrum Team participate in Product Backlog
refinement. When all Development Team members participate, you get two
major benefits. 1) Everyone is part of the discussion of what we are building and
why, which reduces misunderstandings later. 2) Everyone can contribute to the
slicing and ordering of the Product Backlog Items so that they are right-sized and
dependencies are reduced.
•
• The goal of refinement is to get Product Backlog Items to an actionable level of
detail. You may choose to make this more formal with a Definition of Ready. I
like Roman Pichler's description of "ready" as clear, feasible, and testable. Some
teams will create a visual board that shows the refinement of Product Backlog
Items to the state of "Ready."
•
• A Scrum Master coaches the Product Owner on how to best fulfill their role
and responsibilities to the team. The Product Owner is accountable for
 maximizing the value of the product and the work of the Development Team.
Refinement is important so that value is understood and achievable. A Product
Owner does not have to do all of the refinement activity alone (nor should she).
However, if we are seeing symptoms of this problem, a Product Owner may need
to get more engaged in refinement activities. Here are some great questions to
help coach a Product Owner.

3 - Not discussing the "how" during Sprint Planning.

The Sprint Backlog consists of the selected Product Backlog Items and a plan to
deliver them. It is true that this is a loose plan, and the details are expected to emerge
during the Sprint. But that is not an excuse to do a poor job with planning. Discussing
the "how" helps a Development Team better understand how much work they can
forecast for the Sprint. Discussing the "how" helps identify dependencies, gaps in skill
or knowledge, and other impediments. All of these can kill a Sprint if not dealt with
early.

•
• A Scrum Master should reinforce the purpose of Sprint Planning. It is easy
for a team to lose sight of the purpose of an event, and sometimes we just need
a reminder. I ask a team member to kick off the Event by stating the purpose
and output of the Event. Periodically, I ask if the team feels we are making
progress towards that purpose. And at the end of the Event, I ask if everyone
feels that we have achieved the purpose. For Sprint Planning, I ask
what impediments they foresee and need help resolving.
•
• A Scrum Master can help the team more effectively use the time-box. If the
team usually reaches the end of the time-box before talking about the "how,"
break this into two time-boxes to help the team focus on both aspects of the
Sprint Backlog. A back and forth between "what" and "how" is normal, but help
 the team balance this. If the team ends Sprint Planning well before the time-box
without a solid discussion of the "how," use open questions to draw out this part
of the discussion. "This is a large item. How can we break this down into smaller
pieces the team can tackle together?" "Do we have everything we need as a
team to meet our Definition of Done and achieve the Sprint Goal?" "What
dependencies will drive how we deliver on the Sprint Goal?"
•
• Break the Product Backlog Items into tasks or to-dos. Sometimes teams talk
about the "how," but they don't actually capture what they talk about during Sprint
Planning. If you are facilitating the event, you may start capturing some of the
conversation visually on a white board. You may ask if someone can draw what
they are explaining. Offer the team the option to take what they have visually
captured and break down the Product Backlog Items into tasks on the Scrum
Board.
In summary, a Scrum Team must learn to balance emergence and delivery. While there
is no cookie-cutter recipe, we can help our teams use the Product Backlog to prioritize
new work, have more effective Sprint Planning, and improve Product Backlog
refinement.
Understanding the Kanban Guide for Scrum Teams

It’s been so exciting to hear so much positive feedback and interest in the new
Scrum.org Kanban Guide for Scrum Teams and the accompanying Professional Scrum
with Kanban class. Creating the class and guide together with Daniel (Vacanti) & Steve
(Porter) and then working on getting it to market in a professional way (how else? ) with
the Scrum.org staff has been a great experience and a major focus area for me in the
last couple of months.

As you might imagine, together with the interest come some questions about some
choices we made in the design of the guide and the class. Several are emerging as the
frequently asked ones. I wanted to tackle a couple of those in this post.

Where are some of the core Kanban practices?

The major one we’re getting comes from people who are experienced Kanban
practitioners who notice that how we describe Kanban in the Kanban Guide for Scrum
Teams is different than the definition they’re familiar with. (Including my Kanban Primer
for Scrum Teams blog post for example…) This isn’t an oversight. It’s by design. When
we set out to create the Kanban Guide for Scrum Teams/approach we had a specific
context in mind. That context is teams using Scrum according to the Scrum guide,
ideally professionally.

In the Kanban Guide for Scrum Teams, we focus on helping in this context. These
teams already have a collaborative inspect and adapt experimentation process together
with a set of explicit feedback loops they’re using. So, we set out to define the minimal
simplest set of Kanban practices that these Scrum teams would need to add in order to
achieve steadier, healthier, more sustainable flow (I like to say it is like moving from a
sprint that looks like a swamp to one that looks like a river).
After some discussion we decided that these practices actually complement what a
professional Scrum team is already doing :

· Visualization of the workflow

· Limiting WIP

· Active management of work items in progress

· Inspecting and adapting their definition of "Workflow"

While we agree with the importance of “Improve Collaboratively (Using models and the
scientific method” and “Implement feedback loops” we think they are redundant in a
professional Scrum context.

Where are some advanced Kanban concepts like Classes of Service, Cost of Delay,

Flow Efficiency?

They’re not part of the guide because we don’t consider them part of the “Minimally
viable set of practices” a Scrum team should focus on when trying to improve their flow.
Having said that, our guide and especially the PSK class provides people with some
pointers towards advanced complementary Kanban/flow practices/metrics that at least
some can use to continue their learning and improvement journey.

Beyond that - Some of them might be useful in some Scrum contexts, some less so.

Is this an application of the Kanban Method or not?

In my personal view, it is pretty close, as long as you assume professional scrum is your
starting point. (see a blog post I wrote back in 2012 about this context). You are starting
with the way the team uses Scrum and with respecting their current Scrum process &
roles. You are obviously interested in pursuing an incremental evolutionary change to
improve your performance and satisfaction with your process beyond what you’re
currently achieving with Scrum. There is that argument that limiting your work in process
is far from being an evolutionary change but rather a disruptive revolution. My personal
take on it is that yes, limiting your work in process and moving to a disciplined pull mode
is far from being easy, but it’s still evolutionary compared to changing team structures,
roles, process flows. And in any case, this is an argument about the Kanban Method
outside of a Scrum context as well. A professional Scrum team should actually have an
easier time limiting WIP than most.

Is this ScrumBan?

Depends who you ask. Some people’s definition of ScrumBan is “A way to help teams
transition from Scrum to Kanban”. This isn’t what we’re talking about here.

Another definition (that I subscribe to) is to see ScrumBan as a way to introduce Lean/
Kanban flow into a Scrum context – while keeping the core Scrum process intact. This
is pretty similar to our take on the process Scrum teams will typically take to get to an
effective combination of Scrum and Kanban.

Finally, a variant on this definition is to see ScrumBan as simply the Scrum+Kanban

combination itself, without worrying about your starting point and journey. This, in my
view, is indeed what the Kanban Guide for Scrum Teams describes.

Why/When should you add Kanban to Scrum?

The last question I want to tackle is one of the first you might want to think about.
Essentially the question is “Why bother? Isn’t Scrum great as is?”

Most of the teams I’ve worked with since 2010 or so find Scrum+Kanban to be the ideal
mix. I’ve helped Scrum teams achieve an even healthier smoother flow by adding
Kanban to their process. I’ve helped Kanban teams accelerate their pace of
improvement by adding cadence/rhythm and clarity. I’ve helped teams look beyond their
Sprint at the end to end flow all the way from idea to outcomes using a Kanban system.
I’ve helped organizations manage the flow across several Scrum teams using a Kanban
system.

When a Scrum team wants my opinion on whether adding Kanban would be a good
idea I typically ask them to think about how hard it is for them to Sprint and whether they
feel like they have good flow during the Sprint. (And like I mentioned above - do they
feel like their process is a swamp or a river). It’s as simple as that. I find most Scrum
teams struggle to achieve good sustainable healthy flow and Kanban tends to help them
with that.

When is Kanban with Scrum a bad idea?

Some Professional Scrum Trainers asked “When would it be a bad idea to introduce
Kanban to your Scrum? What are some indicators that you should stop using Kanban
as part of your Scrum?” I can’t think of any team where I thought they should stop using
Kanban. If they understand Kanban and do it well, there’s really little that can go wrong.
The problems start when they don’t understand Kanban or use it as an escape from the
challenges of Scrum. Yes, Kanban can help you make your Scrum more sustainable
and healthy, but please don’t add Kanban if you’re looking for an escape from the
difficulties. Kanban done well adds discipline to your Scrum. Another bad time to
introduce Kanban is when the team isn’t looking to improve. If things are working well or
more importantly if the team perceives things as working well, they won’t have the
energy needed to successfully add Kanban to their process. So make sure you agree
on pains/motivations before you move forward to implementing something like Kanban.

Kanban - A way back to Scrum!

To finish with scenarios where introducing Kanban IS a great idea – It pains me every
time I see a team/company using Scrum as a new variant of “project management
command and control” focusing more on tasks, story points, velocity and burndown than
on empiricism leveraging Done Increments of potentially releasable product.

What I’ve noticed is that introducing Kanban ideas helps these teams/companies finally
understand what Scrum really is about and shed a lot of the unnecessary and even
harmful baggage and instead refocus on the transparency, inspection, and adaptation
brought to life by the core Scrum events, roles, and artifacts. Pretty amazing isn’t it?

Interested to learn more about how Kanban and Scrum make each other better
together? Join a public Professional Scrum with Kanban class or request a private
training for your team.
20 Unagile Things to Avoid Saying and Some Better
Alternatives

"See it all. See it fairly. Be truthful, be sensible and be careful with language" - Henry

Grunwald

In Scrum we care about the precise and considered use of language, since any
obfuscation reduces transparency. When we try to implement Scrum, we can
sometimes find that the pressure is on to change Scrum terms and their meaning, so
that change may be "configured" or "customized" to fit the organization. Scrum terms of
reference can become bent and twisted around those existing contours, and the way we
even think about agile change can be tugged at and constrained by organizational
gravity. The result of acquiescing to such pressure is that little change may actually
happen, and there is surprise and disappointment amongst stakeholders when the
expected benefits do not materialize.

We are nevertheless subject to those forces of organizational gravity, and no matter

how rigorous or careful we try to be, we cannot entirely insulate ourselves from its
effects. An important discipline we must therefore learn is to exert small corrections,
early and often, before they build up and we face a crash. Here are twenty small things
which you might be tempted to say or to silently agree with, and which are perhaps
rather better to avoid.

1. Avoid describing a Sprint Backlog as a “commitment”. It’s a “plan” or “forecast” of

work for meeting a Sprint Goal. Use those words instead. Remember that team
members ought to commit to goals, not to forecasts.

2. Avoid language which suggests Story Points are “delivered”, or in some way
constitute value or otherwise proxy for value. The purpose of story pointing is to
help a team forecast how much work it believes it can take on. In agile practice,
 value is only to be found in the delivered increment itself.

3. Avoid talking about an “ideal velocity” when making forecasts. Instead, talk about
the ideal value which can be released in current and future Sprints. Remember
that an agile team does not consist of story point accountants. Speak of the work
done in terms of innovation accounting instead.

4. Avoid talking about “Sprint Goals” when those supposed goals have not yet been
planned and agreed by the team. If they are tentative Sprint Goals, call them
that. During refinement, discuss how well they might align to features and
Minimum Viable Products.

5. Avoid describing stages of work as “Sprints” unless they are time-boxed and
produce an increment of functionality, however small it may be. “Special” sprints
like “sprint zero”, “integration sprint”, “testing sprint” and so on are coded terms
for stages or phases. If stages or phases are to be used, call them so honestly,
and avoid devaluing agile terms of reference.

6. Avoid describing a Sprint Review as a “Show and Tell” or “Demo”. A

demonstration of work might very well form part of a Sprint Review. However, the
essential purpose is to consider the work which has been done and which
remains to be done, and to inspect and adapt the Product Backlog.

7. Avoid talking about a “Kanban” unless there is evidence of a closed economy of

work. If there is merely evidence of a “to-do” list, call it that.

8. Avoid describing Acceptance Criteria as the “Definition of Done”. They may

represent a certain level of “Done” for certain Product Backlog items, but the
Definition of Done, as an assertion of release quality, properly refers to the entire
increment.
9. Avoid referring to a collection of people as a “team” unless there is evidence of
their collaboration and teamwork. If those people are working in silos which are
largely independent of each other, then there may instead be evidence of a
“workgroup” engaged in craft production.

10. Avoid referring to an agile initiative in terms of its supporting tools. Achieving
agile practice is not the same thing as “having Jira” or “using TFS” or indeed any
other technology.

11. Avoid talking about "DevOps" as though it were distinct from agile practice and
cultural change. If you are referring to technical practices such as automation or
continuous integration and deployment, use those terms instead.

12. Avoid talking about “technical debt” when there is no plan to pay the accrued
deficit back, or the liability incurred thus far is unmanaged and unknown. If they
are in truth unquantified losses, call them that.

13. Avoid talking about a “Release Plan” if certain Sprints are not planned to result in
a release at all. What you actually have is a plan for not releasing. In Scrum,
each Sprint must yield an increment of value however small it may be. The
decision to release or not to release ought to be made on a Just in Time basis. A
true Release Plan should outline what is likely to be delivered, to whom and
when...not if a release will happen.

14. Avoid talking about “bugs” or “defects” as if they are separate from other work
which remains to be done. They must still be accounted for as work remaining,
and planned and budgeted for. The urgency of the repair and the speed with
which it is expedited does not obviate the need for this quality of transparency.

15. Avoid talking about “fixed scope” when a Product Backlog is subject to ongoing
refinement, and distinct options might yet emerge. Instead, talk about each Sprint
 as the opportunity to deliver something of value from which useful things can be
learned.

16. Avoid language such as “push to test” which suggests that anything other than a
pull-driven flow of work is expected. Agile and lean practice is founded on pull,
including the timely and efficient handling of work in response to clear demand
signals.

17. Avoid referring to “distributed” teams. A team which is not co-located is a

dislocated team. Call it that, and be transparent and open about the challenges
and inefficiencies concerning teamwork which are likely to arise from such a
model.

18. Avoid using the expression “being agile” as a euphemism for “being reactive” or
doing work “faster and cheaper”. An agile team exhibits full control over its work
in progress and the work it chooses to take on. Any economies will be found in
the team’s ability to inspect and adapt, to evaluate outcomes empirically, and to
reduce waste.

19. Avoid talking about “agile scaling” when the de-scaling of enterprise functions will
be needed before even one team can achieve an agile way of working.

20. Avoid dehumanizing employees as “resources” or “work packages”. If you

contextualize people as inanimate objects, you will get less than the person has
to offer. Employees are human beings with creative and innovative potential.
Value them accordingly.
Forget building trust, focus on psychological safety

Imagine this, you are at the weekly company meeting in a room of 60 people. All of
them are co-workers who you have been working with for several years. You feel
engaged and committed to the goal set by your company. And there has always been a
feeling of openness, respect and the ability to discuss new or other ideas. You feel there
is safety! While the CEO is presenting a new idea, you feel this is not a good idea. You
feel it is in conflict with the company culture. So, like you have always done, you raise
your hand and speak up. Unlike similar earlier situations, your comment gets waved
away, followed by a reprimande of the CEO in front of the entire group:

"I don't like your negative attitude , this idea has been thought of long and hard. I am

sick of you constantly asking about 'why this decision is being made' and you proposing

other ideas, reopening the discussion. Stop doing that!"

How would you feel?

Shocked, humiliated and heartbroken. That's how I felt. In complete shock because I
was under the impression I worked in an psychologically safe environment. We were
enabled - and even expected - to speak up when we had different ideas. That's what
made it a great company. But somewhere along the way, things had changed and I
hadn't noticed there was no longer a safe environment. Actually, there was
psychological safety, from my own team. During the break right after the incident, while I
was sitting at a table looking down, feeling embarrassed, humiliated and fighting against
tears. My team sat down, forming a protective circle around me. No words were spoken,
but it felt very safe. After that moment, safety was gone and hardly anyone spoke up
with a different opinion during those company meetings for a very long time.
Feeling safe

A few weeks ago I found a movie shared by Simon Reindl, fellow Professional Scrum
Trainer, about Psychological safety. This movie made an huge impact on me. I wasn't
aware of the concept but I could relate it to my experience described above. Please
take a few minutes to watch this video.

Try watching this video on www.youtube.com, or enable JavaScript if it is disabled in

your browser.
We have all been in a situation where it didn't feel right or safe to speak up. Or to ask a
question. We all have had those gossip-ish discussions at the coffee machine after the
presentation of the new 5 year strategy, while you had a 5 year strategy presented last
year as well. Or one of those useless team retreats. Take the next step as a team,
where a lot of post-its are spilled with 'world peace' like phrases. In the future we want
to improve our communication, speak up and be proactive. A day not having to work,
get a free lunch and go back to doing the same thing we were already doing. Not feeling
safe to address the elephant in the room.

Psychological safety

Psychological safety is the belief that no one will be punished or humiliated for speaking

up with ideas, questions, concerns or mistakes.

It is a group-level construct, meaning that is something experienced by the entire group.

As a group, each individual perceives that the group will give them the benefit of the
doubt when they take a risk. Opposed to trust, meaning that I as an individual give my
fellow team members the benefit of the doubt when I take a risk. Do I trust my fellow
team members enough they will back me up is an individuals. Basically making a 1-1
economic risk assessment trying to figure out how a certain action will impact my
position in a group.
Trust is a “conscious calculation of advantages, a calculation that in turn is based on an
explicit and internally consistent value system” (Schelling, 1960: 4; ref in Kramer, 1999).
With trust we focus on others potential actions and trustworthiness to protect ourselves.
When we look a psychological safety, it is slightly different. Do others give you the
benefit of the doubt based on your actions?

Not trust but safety!

Over the last couple of years I have referred to the 5 dysfunctions of a team by Patrick
Lencioni in many of our training courses and workshops. And when working with teams,
one of the first items on the agenda was building trust. But trust is the wrong thing to
focus on and more difficult to influence on a team level. Psychological safety is a group
based characteristic based on the level on interpersonal safety each of the members of
the team experience. They often hold similar perceptions of psychological safety.
Because teams have many of the same influences and experiences together. For
example, they often share the same manager, go though the same hiring and review
procedures.

The presence or absence of psychological safety tends to be experienced at the group

level of analysis (Edmondson, 1999a), unlike trust, which pertains primarily to a dyadic

relationship –whether between individuals or collectives such as firms (as in supplier

relationships). -Amy Edmondson, 2003

How to build psychological safety

Even Google has learned that their best teams had psychological safety. It's the first
step towards great teams, it enables innovation, risk taking, group decision making and
much more. Amy Edmondson described three things you can do as a leader to enable
psychological safety.

1. Frame the work as a learning problem, as opposed to an execution problem

So the work we do nowadays is so complex that we cannot know the precise
outcome and which path to follow upfront. However, we have been modeling our
work is such a way. This is why in the past 10 years we are focus more on agility
and this is why the Scrum Framework is so successful, since it accommodated
collaboration in a complex environment. Acknowledging that we know less then
we do know frames the work as a learning problem. Look into the Cynefi n
framework
2. Acknowledge you own fallibility
Acknowledge you don't know everything and inviting people to come to help. For
example, when people use TLA's (Three Letter Abbreviations), ask what they
mean instead of mindless nodding you pretend to understand. You'll be surprised
how hard people need to think about what they actually mean.
3. Model curiosity by asking a lot of questions
The best model on the market to start modeling curiosity is the Scrum
Framework. A lightweight framework with focussed events where asking
questions and engaging in conversation is facilitated. Or like I did once with a
team that tended to assume the customer thought of everything. I asked the
team: "I can think of at least three things that are unclear and I will ask them, I
expect at least three question from you." Worked great and over time they started
asking question by themselves.
There are more steps to take but these are the first and very difficult to do. Start
creating psychological safety in your organizations today! Or you might end up with an
organization where bad things happen for you, for your team members or customers.
How To Pass The Professional Scrum Master Level I (PSM I)

https://litheworks.com/2018/08/14/how-to-pass-the-professional-scrum-master-level-i-psm-i/

The Professional Scrum Master Level I (PSM I) assessment is the first level of Scrum
Master assessments (and associated certifications) offered by Scrum.org. The
Professional Scrum Master Certification from Scrum.org and the Certified Scrum Master
(CSM) Certification from Scrum Alliance are the two most popular entry level Scrum
certifications in the industry right now. Having both of them myself, the PSM I is a far
better assessment of knowledge than the CSM due to CSM requiring only class
attendance for most of its history and then only adding a trivial test (30 questions,
unlimited time, 68% to pass, and unlimited retakes for $25 if you manage to fail it twice)
after facing challenge from the PSM I. Neither assessment is sufficient to guarantee
ability as a Scrum Master, but I believe having the knowledge level to be able to pass
the PSM I is necessary to be successful.

PSM I Assessment Format:

• 80 questions (multiple choice, multiple answer, or true/false).

• 60 min timebox.

• 85% score needed to pass.

• 95% score needed to pass if you are interested in becoming a Professional Scrum
Trainer (this test is one of the first steps in that process).

$150 an attempt or up to 2 free attempts if you take the PSM I class (second attempt is
only free if you take the test within 14 days of the class and don’t pass).
How to prepare for the PSM I assessment:

Read and Re-Read the Scrum Guide and the Glossary. The test is based almost
entirely on the Scrum Guide and your understanding of it. Be able to clearly explain
rules and purpose for the roles, artifacts, and events.

If possible attend a professional scrum master I class which prepares you very well for
this assessment.

Be part of a Scrum team.

Read the recommended blogs and books. If you have not attended a class and not
been part of a well-functioning Scrum team, just reading the Scrum Guide itself will not
likely give you the understanding you need to pass the PSM I assessment. Focus on
the 4 main subject areas for the test (Scrum Framework, Scrum Theory and Principles,
Cross Functional and Self-Organizing Teams, and Coaching and Facilitation).

Interact on the Scrum.org forum for things you are trying to understand.

Be part of a local Scrum or Agile user group to increase your understanding. However
be aware of miss understandings and people using incorrect terms (for example “Daily
Standup” vs the correct “Daily Scrum”).

Understand a few of the visualization techniques that are commonly used by Scrum
Teams.

Burn Down Chart

Burn Up Chart

Planning Poker
Take the Scrum Open assessment, at least 5-10 times getting a 100% score each time
(ideally in under 10 mins a try). If you can’t do this, you likely won’t be able to pass the
real assessment which is much harder. Being able to pass the open assessment is still
not a guarantee of passing. An additional bonus of doing this is that a handful of
questions on the real test will be very similar to the open assessment and will buy you a
couple of extra minutes.

Tips when you are taking the PSM I assessment:

• Plan time for the test when you are alert and won’t be distracted.

• Have the scrum guide and scrum glossary available.

• If you have been through a Professional Scrum Master training class have any of the
class material and notes available as well.

• Watch for questions that are asking for you to pick more than one answer.

• Read questions carefully and watch for “Negatives”.

• If you aren’t sure on an answer, chose an answer anyway and bookmark the question
to come back to later.

• Don’t spent more than 45 seconds on a question on the first pass as you might not
finish the test if you do.

• Use remaining time at the end of the test to review bookmarked questions.

Hope these are helpful tips, and best of luck on the assessment if you choose to take it.
If you have passed the PSM I, consider preparing for the PSM II assessment to further
your learning journey. Feel free to check out our upcoming classes or reach out to us
through our contact us form if you are looking for training for yourself or for your team.
You can also reach out to any member of the Professional Scrum Trainer community.