Adopting an Agile mindset: The Agile

Manifesto
In the previous video, we described Agile project management as an approach to
project and team management based on the Agile Manifesto. In this reading, we will
introduce you to that manifesto, which is made up of four values and 12 principles
that define the mindset that all Agile teams should strive for.

The history of Agile

Agile as a project management approach was introduced to the world in 2001 in the
United States. At a ski resort in the Wasatch mountains of Utah, 17 self-proclaimed
organizational anarchists came together and combined several lightweight
processes to create what we know today as the Agile Manifesto. The creators of
Agile intended it to be a set of values and principles that would improve upon and
transform existing software development processes, but companies in various
industries quickly saw the value of Agile, too. Soon, Agile was adopted across all
fields.

Agile values and principles

In the last video, you explored the Agile Manifesto—the guiding force behind all Agile
teams—in-depth. You learned that Agile is a highly collaborative approach suited for
very complex and competitive projects. In this reading, we’ll briefly explore the four
values and 12 principles of the Agile Manifesto.

The Agile values refer to the following four statements:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
Agile experts see these values as important underpinnings of the highest performing
teams, and every team member should strive to live by these values to apply the full
benefits of Agile.

The same is true for the 12 principles, which are at the core of every Agile project:

 “Our highest priority is to satisfy the customer through early

and continuous delivery of valuable software.” Whether you are
working to create a product for your company or for a customer, chances are
that someone is awaiting its delivery. If that delivery is delayed, the result is that
the customer, user, or organization is left waiting for that added value to their
lives and workflows. Agile emphasizes that delivering value to users early and
often creates a steady value stream, increasing you and your customer’s
success. This will build trust and confidence through continuous feedback as
well as early business value realization.
 “Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s
competitive advantage.” When working in Agile, it’s important to be
agile. That means being able to move swiftly, shifting direction whenever
necessary. That also means that you and your team are constantly scanning
your environment to make sure necessary changes are factored into the plans.
Acknowledging and embracing that your plans may change (once, twice, or
several times) ensures that you and your customers are maximizing your
success.
 “Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.” Delivering your product in small, frequent increments is important
because it allows time and regular opportunities for stakeholders—including
customers—to give feedback on its progress. This ensures that the team never
spends too much time going down the wrong path.
 “Business people and developers must work together daily
throughout the project.” Removing barriers between developers and
people focused on the business side of the project, builds trust and
understanding and ensures that the developers, or those building the solution,
are in tune with the needs of the users.
 “Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.” A successful Agile team includes team members that not only
trust each other to get the work done but are also trusted by their sponsors and
executives to get the work done. Teams build better solutions when they are
empowered and motivated to deliver difficult projects.
 “The most efficient and effective method of information to and
within a development is face-to-face conversation.” There isn’t
anything quite like face-to-face communication. Face-to-face communication
allows us to catch certain cues, body language, and facial expressions that are
sometimes lost when using forms of communication like email, chat, or the
phone. However, we can’t always be face-to-face. Establishing effective
communication norms—no matter the format—is essential to effective teams.
 “Working software is the primary measure of progress.” In
Agile teams, the main way to demonstrate meaningful completion of work is to
show a working piece of the solution. In software teams, that might mean a
functional piece of software. In non-software teams, that might mean a critical
portion of the solution that is ready to be demonstrated to users or their
representatives in order to collect feedback. This is in contrast to traditional or
Waterfall projects, where the completion of project documents could be used to
measure progress. In Agile project management, it is not enough to say that the
team is 80% done with an activity if there is no working, demonstrable artifact
available to review.
 “Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.” Maintaining a steady but careful pace will
prevent errors along the way. Also, you never want your team to feel
overworked or overwhelmed. On the flip side, a team that is underutilized may
become bored and lose the creative spark to innovate. The Agile ideal is to
achieve a steady pace of effort for the team that avoids overtime and burnout.
  “Continuous attention to technical excellence and good design
enhances agility.” This principle conveys that just because the team is
working fast doesn’t mean they sacrifice quality. By emphasizing quality and
design throughout the project development phase, the agility, efficiency, and
speed of the team will be increased. When a team delivers a well-built solution,
they can quickly respond to user feedback and new information. However, if the
product is low quality, implementing changes can become problematic, complex,
and slow down the entire team.
 “Simplicity—the art of maximizing the amount of work not
done—is essential.” The team should avoid implementing extra features
into the solution that weren’t explicitly requested by the user or product owner.
This includes removing procedures that are no longer necessary, and reducing
unnecessary documentation.
 “The best architectures, requirements, and designs emerge
from self-organizing teams.” Team members should be able to get their
work done by designing their own work processes and practices, without a
manager dictating how they operate. Team members should also feel
empowered to speak up with questions, concerns, or feedback.
 “At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.” In Agile, it is important to acknowledge that learning from
successes and failures is continuous. No team is perfect. There will be
mistakes, challenges, trials, and triumphs. Teams should reflect on all of these
different aspects of their activities so that they can make necessary
adjustments.
For additional information, read more on the 12 principles here.

The founding principles of Scrum

In this reading, you will learn to define the characteristics of Scrum as we review
what makes Scrum different from other frameworks.

Although Scrum was first used to describe Agile content in 1986 in the Harvard
Business Review, the term originates from the internationally loved sport, rugby. In
rugby, a “scrum” involves players huddling closely together with their heads down
while trying to gain possession of the ball. Then, the players work together in order to
achieve their shared goal: to get the ball across the line and score!

The original Harvard Business Review paper, written by Hirotaka Takeuchi and Ikujiri
Nonaka and titled The New New Product Development Game, introduces Scrum in
the chapter “Moving the Scrum downfield.” Throughout the paper, the authors
continue to point out which characteristics of a team help to move the Scrum
downfield. Those are:

 Built-in instability: In the Scrum world, teams are given the freedom to
achieve important outcomes with “challenging requirements.” Takeuchi and
 Nonaka explain that this gives teams “an element of tension” necessary to “carry
out a project of strategic importance to the company.”
 Self-organizing teams: Scrum Teams were intended to operate like their
own start-up, with a unique order that lacks true hierarchy. These teams are
considered self-organizing when they exhibit autonomy, continuous growth, and
collaboration.
 Overlapping development phases: Individuals on a Scrum Team must
“work toward synchronizing their pace to meet deadlines.” At some point
throughout the process, each individual’s pace starts to overlap with others, and
eventually, a collective pace is formed within the team.
 Multi-learning: Scrum is a framework that relies heavily on trial and error.
Scrum Team members also aim to stay up-to-date with changing market
conditions and can then respond quickly to those conditions.
 Subtle control: As we mentioned, Scrum Teams are self-organizing and
operate like a start-up, but that doesn’t mean there is no structure at all. By
creating checkpoints throughout the project to analyze team interactions and
progress, Scrum Teams maintain control without hindering creativity.
 Organizational transfer of learning: On Scrum Teams, everyone is
encouraged to learn skills that may be new to them as they support other team
members.
The authors’ main point was that “each element, by itself, does not bring about
speed and flexibility. But taken as a whole, the characteristics can produce a
powerful new set of dynamics that will make a difference.” Though these concepts
were first introduced in 1986, they still remain remarkably true for Scrum Teams
today.

The Spotify model

Because of their flexible approach, Spotify—a music streaming company with
millions of listeners—is known in the Agile project management field for setting the
standard pretty high. In this reading, you will learn about the Spotify model and the
importance of being flexible when scaling an Agile team.

Spotify has been able to do what so many other companies dream of doing, and
they’ve done it as their team size scaled. How did they do it? Agile coaches Henrik
Kniberg and Anders Ivarsson have instilled an overall approach of the constant
blending of methods and adapting as time goes on.

The Spotify model

The Spotify model encourages innovation, collaboration, and productivity while
maintaining autonomy, quality, and necessary communication. It does so by using a
unique organization system that features Squads, Tribes, Chapters, and Guilds.

At Spotify, teams are broken down into what they call Squads. A Squad is like a
Scrum Team and is supposed to feel like its own start-up within the company.
Squads are self-organizing and collocated. They work together to achieve a long-
term mission. At Spotify, a Squad may be in charge of a task such as improving the
app’s usability for Android, improving the Spotify radio experience, or providing
payment solutions. Just like a Scrum Team, the Squad doesn't have a formal leader,
but they do have a Product Owner. Product Owners collaborate with one another to
maintain a roadmap to track Spotify’s progress as a whole. Each team also has
access to an Agile coach to encourage continuous improvements.
Be inspired by the Spotify model, but don’t
emulate it
Each team requires differences in their workflow and systems. It is never a good idea
to try to copy and paste an exact model to your team just because it worked for
another team. In fact, some people have tried copying Spotify’s model and found that
it was not a suitable model for their team at all.

Key takeaways
 You must always be able to adapt based on your team’s
preferences and goals. The Spotify team started in Squads, but as they
scaled, they added new types of groups within the organization—without
disrupting the existing Squads. They continued to do so until they found the
perfect balance of collaboration and ownership.
 Always examine the needs of your project and organization.
What works for Spotify may not be an exact fit for your team. If you are on a
team that needs scaling, be inspired by this model, but use the aspects that
work best for your organization.
 Don’t be afraid of trial and error. If you try something and it doesn’t
feel quite right, you can easily adjust.
 You should never consider yourself done improving. There are
always changes that can be made for the better.

The Scrum Guide

In the last video, you learned that the Scrum Guide acts as the main source of truth
for Scrum teams and contains everything you need to know about Scrum. You also
learned that Scrum is a framework within the foundational project management
philosophy called Agile. The Scrum Guide defines Scrum as “A framework within
which people can address complex adaptive problems, while productively and
creatively delivering products of the highest possible value.” This reading will review
the Scrum pillars and values and then provide links to the Scrum Guide and further
reading about Scrum.

Pillars and values

To recap, every person on a Scrum team subscribes to the three pillars and the five
values of Scrum. The three pillars of Scrum are:

 Transparency
 Inspection
 Adaptation
The five values of Scrum are:

 Courage
 Commitment
 Focus
  Openness
 Respect
In order for a team to succeed, it is incredibly important that every team member
follow these core pillars and values.

Scrum only has a few rules and practices that are easy to follow. It is also easy to
understand. However, Scrum can be challenging to master because mastery
depends on being able to embody, live, and promote the pillars and values of
Scrum.

Helpful links
Take a deeper look at the framework in the Scrum Guide. For further reading about
Scrum, check out Scrum.org.

Understanding Scrum Team roles

Each Scrum Team member plays a vital role in the project’s success. In order to help
a project get to the finish line, you will need to understand what each of these roles
entail. In this reading, you will learn how the responsibilities of the Scrum Master,
Product Owner, and Development Team differ from one another.

The Scrum Master

One key responsibility of the Scrum Master is to help the team understand and
follow Scrum theory. More specifically, according to the Scrum Guide, “The Scrum
Master is accountable for establishing Scrum as defined in the Scrum Guide. They
do this by helping everyone understand Scrum theory and practice, both within the
Scrum Team and the Organization. The Scrum Master is accountable for the Scrum
Team’s effectiveness. They do this by enabling the Scrum Team to improve its
practices, within the Scrum framework.” The Scrum Master makes sure that
important meetings occur, like the Daily Scrum. In the same way that a coach would
be aware of the game clock, the Scrum Master is tasked with making sure that the
meeting is kept within the appropriate timebox. A timebox is a Scrum concept that
refers to the estimated duration for an event.

The Scrum Master acts as a coach to the Scrum Team—they encourage the team to
build the product in the time frame. They also support the team by creating a
collaborative environment so the project’s goals are achieved. The Scrum Master’s
duties include:

 Coaching the team members in self-management and cross-functionality

 Helping the Scrum Team focus on creating high-value Increments that meet the
Definition of Done (an agreed upon set of items that must be completed
before a project or user story can be considered complete)
 Causing the removal of impediments to the Scrum Team’s progress
 Ensuring that all Scrum events take place and are positive, productive, and kept
within the timebox (a Scrum concept that refers to the estimated duration for
an event)
Scrum Master vs. project manager
The role of the Scrum Master is sometimes confused with the role of the project
manager. While the two roles share related skills and qualities, they are very
different roles.

A Scrum Master is responsible for helping the team understand Scrum theory and
practice. They ensure Scrum events take place and help the team focus on
delivering value by removing impediments. But unlike a traditional project manager,
they do not take on the management of changes in scope or priorities. Additionally,
Scrum Masters do not maintain traditional project artifacts like Gantt charts.

The Product Owner

According to the Scrum Guide, “The Product Owner is responsible for
maximizing the value of the product resulting from work of the Scrum Team. How
this is done may vary widely across organizations, Scrum Teams, and individuals.”
Product Owners maximize the value of the product by representing and expressing
the voice of the customer throughout the project duration. A product isn’t useful to its
customers if that product doesn’t fulfill their expectations and meet their needs. The
Product Owner’s duties include:

 Developing and explicitly communicating the Product Goal

 Creating and clearly communicating Product Backlog items (The Product
Backlog contains all of the features, requirements, and activities associated with
deliverables to achieve the goal of the project.)
 Ensuring that the Product Backlog is transparent, visible, and understood

Product Owner vs. project manager

In traditional project management, scope management is the primary responsibility
of the project manager. But in Scrum, the definition and management of product
scope falls to the Product Owner. Conversely, the Product Owner isn’t responsible
for team performance—they aren’t considered to be a manager. The project
manager leads the project team to meet the project’s objectives and oversees tasks
and progress.

There are also similarities between the Product Owner and project manager roles.
For instance, both roles are tasked with stakeholder management. This means they
both must practice and facilitate effective communication among team members and
stakeholders.

Additionally, in many companies—including Google—the definition of product or

solution scope is the responsibility of a separate role called a product manager.
So, it is important when joining any new company to discover how that company
approaches the area of product definition, requirements development, and user
research to understand what they consider to be the domain of the project manager.
The Development Team
The Development Team, also referred to as Developers, is made up of the
people who do the work to build the product. According to the Scrum Guide,
Developers are “the people in the Scrum Team that are committed to creating any
aspect of a usable Increment each Sprint.” Their responsibilities include:

 Creating a plan for the Sprint, the Sprint Backlog (the set of Product Backlog
items that are selected to be completed during the upcoming Sprint)
 Instilling quality by adhering to a Definition of Done
 Adapting their plan each day toward the Sprint Goal
 Holding each other accountable as professionals
 Executing sprints by designing, building, and testing Product Backlog items in
increments
An important aspect of the Development Team that is worth highlighting is that they
are cross-functional, meaning that you will have team members who are specialists
in different disciplines. In a software team, that might mean having a web developer,
a database developer, and a user experience specialist. In a marketing team, that
might mean having writers, editors, search engine optimization specialists, and
business analysts.

The roles working together

The Scrum roles fit together, and each brings their unique qualities, skills, and
responsibilities jointly to lead to successful Scrum projects. It is crucial for everyone
on the team to understand their role and how they work together to deliver value to
their users and customers. When the team has this shared understanding, they can
better support each other during the practices of Scrum.

Necessary traits for each role

Overall, you will want people on your team who are interested in constant
collaboration and improvement. More specifically, it is great to have team members
who value feedback, bring energy and fun to the team, and can admit and learn from
their mistakes. Let’s look at what traits each team member should exhibit:

The Product Owner should be able to confidently provide the team with general
direction, requirements, and objectives for the project but will allow the team to
determine how to accomplish these goals. Your team will want a Product Owner who
promotes the product vision and prioritizes the product backlog to maximize the
value for the customer. In order to deliver on this, the Product Owner should be
organized and have strong communication skills.

The Scrum Master should have strong leadership skills that enable them to be
efficient facilitators and negotiators who know how to resolve conflict. Your team will
want a Scrum Master who aims to effectively coach the Development Team,
facilitate events, and eliminate distractions that may impede the team’s progress.

When it comes to the Development Team, you will want individuals who remain
focused on completing deliverables and producing a superior final product. Since the
team is self-organizing and cross-functional, you will want people who are eager to
work together and not afraid to compromise for the greater good of the product.

Characteristics of a Great Scrum Team

According to the Scrum Guide, Scrum is a framework within which people
can address complex problems, and productively and creatively develop
products of the highest possible value. It's a tool organizations can use to
increase their agility.
 Within Scrum self-organizing, cross-functional, and highly productive
teams do the work: creating valuable releasable product increments.
Scrum offers a framework that catalyzes the teams learning through
discovery, collaboration and experimentation.

A great Scrum Team consists of a Product Owner who maximizes value, a

Scrum Master who enables continuous improvement and a Development
Team who focus on delivering high quality product increments.

For sure this sounds great!

But what are the characteristics of such a great Scrum team? This white
paper will answer that question. It offers a detailed description of the
characteristics and skills of a great Product Owner, Scrum Master and
Development Team.

The Product Owner

The Product Owner is responsible for maximizing the value of the product
and the work of the Development Team. It's a one-person role that brings
the customer perspective of the product to a Scrum Team.

The Product Owner is responsible for:

 Developing and maintaining a product vision and market strategy;
 Product management;
 Ordering and managing the Product Backlog;
 Involving stakeholders and end-users in Product Backlog refinement and
backlog management;
 Alignment with other Product Owners when needed from an overall
product, company or customer perspective.

A Great Product Owner...

 Embraces, shares and socializes the product vision. A great Product
Owner represents the customers voice and creates a product vision
together with the stakeholders. Every decision is taken with the product
vision in mind. This ensures sustainable product development, provides
clarity for the development team and increases the chances of product
success drastically.
 Exceeds the customer’s expectation. A great Product Owner truly
understands the customer’s intentions and goals with the product and is
able to outstrip its expectations. Customer delight is the ultimate goal!
 Is empowered. A great Product Owner is empowered to take decisions
related to the product. Sure, creating support for his decisions might take
some time, but swiftly taking important decisions is a primary condition
for a sustainable pace of the development team.
 Orders the product backlog. A great Product Owner understands that
the product backlog should be ordered. Priority, risk, value, learning
opportunities and dependencies are all taken into account and balanced
with each other. For example, when building a house the roof might have
the highest priority considering possible rain. But still it's necessary to
realize the foundation and walls earlier and therefore order them above
the construction of the roof.
 Prefers face-to-face communication. A great Product Owner
understands that the best way to convey information is face-to-face
communication. User stories are explained in a personal conversation. If a
tool is used for backlog management, its function is to support the
dialogue. It never replaces the good old-fashioned conversation.
 Knows modeling techniques. A great Product Owner has a backpack
full of valuable modeling techniques. He knows when to apply a specific
model. Examples are Business Model Generation, Lean Startup or Impact
Mapping. Based on these models he knows how to drive product success.
 Shares experiences. A great Product Owner shares experiences with
peers. This might be within the organization, and outside it: seminars and
conferences are a great way to share experiences and gather knowledge.
In addition, writing down your lessons learned can be valuable for other
Product Owners.
 Owns user story mapping. A great Product Owner should master the
concept of user story mapping. It's a technique that allows you to add a
second dimension to your backlog. The visualization enables you to see
the big picture of the product backlog. Jeff Patton wrote some excellent
material about the concept of story mapping.
 Has a focus on functionality. A great Product Owner has a focus on
functionality and the non-functional aspects of the product. Hours or even
story points are less important. The goal of the Product Owner is to
maximize value for the customer. It’s the functionality that has value;
therefore this is the main focus for the Product Owner.
 Is knowledgeable. A great Product Owner has in depth (non-)functional
product knowledge and understands the technical composition. For large
products it might be difficult to understand all the details, and scaling the
Product Owner role might be an option. However the Product Owner
should always know the larger pieces of the puzzle and hereby make
conscious, solid decisions.
 Understands the business domain. A great Product Owner
understands the domain and environment he's part of. A product should
always be build with its context taken into account. This includes
understanding the organization paying for the development but also being
 aware of the latest the market conditions. Shipping an awesome product
after the window of opportunity closes is quite useless.
 Acts on different levels. A great Product Owner knows how to act on
different levels. The most common way to define these levels is strategic,
tactical and operational. A Product Owner should know how to explain the
product strategy at board level, create support at middle management
and motivate the development team with their daily challenges.
 Knows the 5 levels of Agile planning. Within Agile, planning is done
continuously. Every product needs a vision (level 1) which will provide
input to the personal (level 2). The roadmap is a long range strategic plan
of how the business would like to see the product evolve. Based on the
roadmap, market conditions and status of the product the Product Owner
can plan releases (level 3). During the Sprint Planning (level 4) the team
plan and agree on Product Backlog Items they are confident they can
complete during the Sprint and help them achieve the Sprint Goal. The
Daily Scrum (level 5) is used to inspect and adapt the team's progress
towards realizing the Sprint Goal.
 Is available. A great Product Owner is available to the stakeholders, the
customers, the development team and the Scrum Master. Important
questions are answered quickly and valuable information is provided on
time. The Product Owner ensures his availability never blocks the progress
of the development team.
 Is able to say 'no'. A great Product Owner knows how and when to say
no. This is probably the most obvious but most difficult characteristic to
master. Saying yes to a new idea or feature is easy, it's just another item
for the product backlog. However, good backlog management
encompasses creating a manageable product backlog with items that
probably will get realized. Adding items to the backlog knowing nothing
will happen with them only creates 'waste' and false expectations.
 Acts as a "Mini-CEO". A great Product Owner basically is a mini-CEO for
his product. He has a keen eye for opportunities, focuses on business
value and the Return On Investment and acts proactive on possible risks
and threats. Everything with the growth (size, quality, market share) of his
product taken into account.
 Knows the different types of valid Product Backlog items. A great
Product Owner can clarify the fact that the Product Backlog consists of
more than only new features. Fore example: technical innovation, bugs,
defects, non-functional requirements and experiments, should also be
taken into account.
 Takes Backlog Refinement seriously. A great Product Owner spends
enough time refining the Product Backlog. Backlog Refinement is the act
of adding detail, estimates and order to items in the Product Backlog. The
outcome should be a Product Backlog that is granular enough and well
understood by the whole team. On average the Development Team
spends no more than 10% of the capacity of the Development Team on
refinement activities. The way it is done isn’t prescribed and is up to the
team. The Product Owner can involve stakeholders and the Development
Team in backlog refinement. The stakeholders because it gives them the
opportunity to explain their wishes and desires. The Development Team
 because they can clarify functional and technical questions or
implications. This will ensure common understanding and increases the
quality of the Product Backlog considerably. As a consequence, the
opportunity to build the right product with the desired quality will also
increase.

The Scrum Master

According to the Scrum Guide the Scrum Master is responsible for
ensuring Scrum is understood and enacted. Scrum Masters do this by
ensuring that the Scrum Team adheres to Scrum theory, practices, and
rules. The Scrum Master is a servant-leader for the Scrum Team. The
Scrum Master helps those outside the Scrum Team understand which of
their interactions with the Scrum Team are helpful and which aren’t. The
Scrum Master helps everyone change these interactions to maximize the
value created by the Scrum Team.

The role of a Scrum Master is one of many stances and diversity. A great
Scrum Master is aware of them and knows when and how to apply them,
depending on situation and context. Everything with the purpose of
helping people understand and apply the Scrum framework better.

The Scrum Master acts as a:

 Servant Leader whose focus is on the needs of the team members and
those they serve (the customer), with the goal of achieving results in line
with the organization's values, principles, and business objectives;
 Facilitator by setting the stage and providing clear boundaries in which
the team can collaborate;
 Coach coaching the individual with a focus on mindset and behaviour, the
team in continuous improvement and the organization in truly
collaborating with the Scrum team;
 Conflict navigator to address unproductive attitudes and dysfunctional
behaviors;
 Manager responsible for managing impediments, eliminate waste,
managing the process, managing the team's health, managing the
boundaries of self-organization, and managing the culture;
 Mentor that transfers agile knowledge and experience to the team;
 Teacher to ensure Scrum and other relevant methods are understood
and enacted.

A Great Scrum Master...

 Involves the team with setting up the process. A great Scrum Master
ensures the entire team supports the chosen Scrum process and
 understands the value of every event. The daily Scrum for example is
planned at a time that suits all team members. A common concern about
Scrum is the amount of 'meetings', involving the team with planning the
events and discussing the desired outcome will increase engagement for
sure.
 Understands team development. A great Scrum Master is aware of the
different phases a team will go through when working as a team. He
understands Tuckman's different stages of team development: forming,
storming, norming, performing and adjourning. The importance of a stable
team composition is therefore also clear.
 Understands principles are more important than practices. Without
a solid, supported understanding of the agile principles, every
implemented practice is basically useless. It's an empty shell. An in-depth
understanding of the agile principles by everyone involved will increase
the chances of successful usage of practices drastically.
 Recognizes and acts on team conflict. A great Scrum Master
recognizes team conflict in an early stage and can apply different
activities to resolve it. A great Scrum Master understands conflict isn't
necessarily wrong. Healthy conflict and constructive disagreement can be
used to build an even stronger team.
 Dares to be disruptive. A great Scrum Master understands some
changes will only occur by being disruptive. He knows when it's necessary
and is prepared to be disruptive enough to enforce a change within the
organization.
 Is aware of the smell of the place. A great Scrum Master can have an
impact on the culture of the organization so that the Scrum teams can
really flourish. He understands that changing people's behavior isn't about
changing people, but changing the context which they are in: the smell of
the place.
 Is both dispensable and wanted. A great Scrum Master has supported
the growth of teams in such a manner they don't need him anymore on
daily basis. But due to his proven contribution he will get asked for advice
frequently. His role has changed from a daily coach and teacher to a
periodical mentor and advisor.
 Let his team fail (occasionally). A great Scrum Master knows when to
prevent the team from failing but also understands when he shouldn't
prevent it. The lessons learned after a mistake might be more valuable
than some good advice beforehand.
 Encourages ownership. A great Scrum Master encourages and coaches
the team to take ownership of their process, task wall and environment.
 Has faith in self-organization. A great Scrum Master understands the
power of a self-organizing team. "Bring it to the team" is his daily motto.
Attributes of self-organizing teams are that employees reduce their
dependency on management and increase ownership of the work. Some
examples are: they make their own decisions about their work, estimate
their own work, have a strong willingness to cooperate and team
members feel they are coming together to achieve a common purpose
through release goals, sprint goals and team goals.
 Values rhythm. A great Scrum Master understands the value of a steady
sprint rhythm and does everything to create and maintain it. The sprint
rhythm should become the team’s heartbeat, which doesn't cost any
energy. Everyone knows the date, time and purpose of every Scrum
event. They know what is expected and how to prepare. Therefore a
complete focus on the content is possible.
 Knows the power of silence. A great Scrum Master knows how to truly
listen and is comfortable with silence. Not talking, but listening. He is
aware of the three levels of listening - level 1 internal listening, level 2
focused listening, level 3 global listening, and knows how to use them. He
listens carefully to what is said, but also to what isn't said.
 Observes. A great Scrum Master observes his team with their daily
activities. He doesn't have an active role within every session. The daily
Scrum, for example, is held by the team for the team. He observes the
session and hereby has a more clear view to what is being discussed (and
what isn't) and what everyone’s role is during the standup.
 Shares experiences. Great Scrum Masters shares experiences with
peers. This might be within the organization, but also seminars and
conferences are a great way to share experiences and gather knowledge.
Of course writing down and sharing your lessons learned is also highly
appreciated. And yes, for the attentive readers, this is exactly the same as
for the Product Owner and the Development Team.
 Has a backpack full of different retrospective formats. A great
Scrum Master can apply lots of different retrospective format. This
ensures the retrospective will be a fun and useful event for the team. He
knows what format is most suitable given the team's situation. Even
better: he supports the team by hosting their own retrospective. To
improve involvement this is an absolute winner!
 Can coach professionally. A great Scrum Master understands the
power of professional coaching and has mastered this area of study.
Books like Coaching Agile Teams and Co-Active Coaching don't have any
secrets for him. He knows how to guide without prescribing. He can close
the gap between thinking about doing and actually doing; he can help the
team members understand themselves better so they can find news ways
to make the most of their potential. Yes, these last few sentences are
actually an aggregation of several coaching definitions, but it sounds quite
cool!
 Has influence at organizational level. A great Scrum Master knows
how to motivate and influence at tactic and strategic level. Some of the
most difficult impediments a team will face occur at these levels;
therefore it's important a Scrum Master knows how to act at the different
levels within an organization.
 Prevent impediments. A great Scrum Master not only resolves
impediments, he prevents them. Due to his experiences he is able to
'read' situations and hereby act on them proactively.
 Isn't noticed. A great Scrum Master isn't always actively present. He
doesn't disturb the team unnecessary and supports the team in getting
into the desired 'flow'. But when the team needs him, he's always
available.
 Forms a great duo with the Product Owner. A great Scrum Master
has an outstanding partnership with the Product Owner. Although their
interests are somewhat different, the Product Owner 'pushes' the team,
the Scrum Master protects the team. A solid partnership is extremely
valuable for the Development Team. Together they can build the
foundation for astonishing results.
 Allows leadership to thrive. A great Scrum Master allows leadership
within the team to thrive and sees this as a successful outcome of their
coaching style. They believe in the motto "leadership isn't just a title, it's
an attitude". And it's an attitude everyone in the team can apply.
 Is familiar with gamification. A great Scrum Master is able to use the
concepts of game thinking and game mechanics to engage users in
solving problems and increase users' contribution.
 Understands there's more than just Scrum. A great Scrum Master is
also competent with XP, Kanban and Lean. He knows the strengths,
weaknesses, opportunities and risks of every method/framework/principle
and how & when to use them. He tries to understand what a team wants
to achieve and helps them become more effective in an agile context.
 Leads by example. A great Scrum Master is someone that team
members want to follow. He does this by inspiring them to unleash their
inner potential and showing them the desired behavior. At difficult times,
he shows them how to act on it; he doesn't panic, stays calm and helps
the team find the solution. Therefore a great Scrum Master should have
some resemblance to Gandalf. The beard might be a good starting point :)
 Is a born facilitator. A great Scrum Master has facilitation as his second
nature. All the Scrum events are a joy to attend, and every other meeting
is well prepared, useful and fun, and has a clear outcome and purpose.

The Development Team

According to the Scrum Guide the Development Team consists of
professionals who do the work of delivering a potentially releasable
Increment of “Done” product at the end of each Sprint. Only members of
the Development Team create the Increment. Development Teams are
structured and empowered by the organization to organize and manage
their own work. The resulting synergy optimizes the Development Team’s
overall efficiency and effectiveness.

Development Teams have the following characteristics:

 Self-organizing. They decide how to turn Product Backlog Items into
working solutions.
 Cross-functional. As a whole, they've got all the skills necessary to create
the product Increment.
 No titles. Everyone is a Developer, no one has a special title.
 No sub-teams in the Development team.
 Committed to achieving the Sprint Goal and delivering a high quality
increment

A Great Development Team

 Pursues technical excellence. Great Development Teams use Extreme
Programming as a source of inspiration. XP provides practices and rules
that revolve around planning, designing, coding and testing. Examples are
refactoring (continuously streamlining the code), pair programming,
continuous integration (programmers merge their code into a code
baseline whenever they have a clean build that has passed the unit tests),
unit testing (testing code at development level) and acceptance testing
(establishing specific acceptance tests).
 Applies team swarming. Great Development Teams master the concept
of 'team swarming'. This is a method of working where a team works on
just a few items at a time, preferably even one item at a time. Each item
is finished as quickly as possible by having many people work on it
together, rather than having a series of handoffs.
 Uses spike solutions. A spike is a concise, timeboxed activity used to
discover work needed to accomplish a large ambiguous task. Great
Development Teams uses spike experiments to solve challenging
technical, architectural or design problems.
 Refines the product backlog as a team. Great Development Teams
consider backlog refinement a team effort. They understand that the
quality of the Product Backlog is the foundation for a sustainable
development pace and building great products. Although the Product
Owner is responsible for the product backlog, it's up to the entire team to
refine it.
 Respects the Boy Scout Rule. Great Development Teams use the Boy
Scout Rule: always leave the campground cleaner than you found it.
Translated to software development: always leave the code base in a
better state than you've found it. If you find messy code, clean it up,
regardless of who might have made the mess.
 Criticizes ideas, not people. Great Development Teams criticize ideas,
not people. Period.
 Share experiences. Great Development Teams share experiences with
peers. This might be within the organization, but also seminars and
conferences are a great way to share experiences and gather knowledge.
Of course writing down and sharing your lessons learned is also highly
appreciated. And yes, for the attentive readers, this is exactly the same as
for the Product Owner.
 Understands the importance of having some slack. Great
Development Teams have some slack within their sprint. Human beings
can't be productive all day long. They need time to relax, have a chat at
the coffee machine or play table football. They need some slack to be
innovative and creative. They need time to have some fun. By doing so,
they ensure high motivation and maximum productivity. But slack is also
 necessary to handle emergencies that might arise; you don't want your
entire sprint to get into trouble when you need to create a hot-fix.
Therefore: build in some slack! And when the sprint doesn't contain any
emergencies: great! This gives the team the opportunity for some
refactoring and emergent design. It's a win-win!
 Has fun with each other. Great Development Teams ensure a healthy
dose of fun is present every day. Fostering fun, energy, interaction and
collaboration creates an atmosphere in which the team will flourish!
 Don't have any Scrum 'meetings'. Great Development Teams consider
the Scrum events as opportunities for conversations. Tobias Mayer
describes this perfectly in his book ‘The Peoples Scrum': “Scrum is
centered on people, and people have conversations. There are
conversations to plan, align, and to reflect. We have these conversations
at the appropriate times, and for the appropriate durations in order to
inform our work. If we don’t have these conversations, we won’t know
what we are doing (planning), we won’t know where we are going
(alignment), and we’ll keep repeating the same mistakes (reflection).”
 Knows their customer. Great Development Teams know their real
customer. They are in direct contact with them. They truly understand
what they desire and are therefore able to make the right (technical)
decisions.
 Can explain the (business) value of non-functional
requirements. Great Development Teams understand the importance for
non-functional requirements like e.g. performance, security and
scalability. They can explain the (business) value to their Product Owner
and customer and hereby ensure its part of the product backlog.
 Trust each other. Great Development Teams trust each other. Yes, this
is obvious. But without trust it's impossible for a team to achieve
greatness.
 Keep the retrospective fun. Great Development Teams think of
retrospective formats themselves. They support the Scrum Master with
creative, fun and useful formats and offer to facilitate the sessions
themselves.
 Deliver features during the sprint. Great Development Teams deliver
features continuously. Basically they don't need sprints anymore.
Feedback is gathered and processed whenever an item is ‘done’; this
creates a flow of continuous delivery.
 Don't need a sprint 0. Great Development Teams don't need a sprint 0
before the 'real' sprints start. They are able to deliver business value in
the first sprint.
 Acts truly cross-functional. Great Development Teams not only have a
cross-functional composition and act truly cross-functionally. They don't
talk about different roles within the team but are focused on delivering a
releasable product each sprint as a team. Everyone is doing the stuff
that's necessary to achieve the sprint goal.
 Updates the Scrum board themselves. Great Development Teams
ensure the Scrum/team board is always up-to-date. It's an accurate
reflection of the reality. They don't need a Scrum Master to encourage
 them; instead they collaborate with the Scrum Master to update the
board.
 Spends time on innovation. Great Development Teams understand the
importance of technical/architectural innovation. They know it's necessary
to keep up with the rapidly changing environment and technology. They
ensure they have time for innovation during regular working hours, and
that it's fun and exciting!
 Don't need a Definition of Done. Great Development Teams deeply
understand what 'done' means for them. For the team members, writing
down the Definition of Done isn't necessary anymore. They know. The only
reason to use it is to make the 'done state' transparent for their
stakeholders.
 Knows how to give feedback. Great Development Teams have learned
how to give each other feedback in an honest and respectful manner.
They grasp the concept of the 'Situation - Behavior - Impact Feedback
Tool' and hereby provide clear, actionable feedback. They give feedback
whenever it's necessary, and don't postpone feedback until the
retrospective.
 Manages their team composition. Great Development Teams manage
their own team composition. Whenever specific skills are necessary, they
collaborate with other teams to discuss the opportunities of 'hiring'
specific skills.
 Practice collective ownership. Great Development Teams understand
the importance of collective ownership. Therefore they rotate developers
across different modules of the applications and systems to encourage
collective ownership.
 Fix dependencies with other teams. Great Development Teams are
aware of possible dependencies with other teams and manage these by
themselves. Thereby ensuring a sustainable development pace for the
product.
 Don't need story points. Great Development Teams don't focus on
story points anymore. They've refined the product backlog so that the size
for the top items don’t vary much. They know how many items they can
realize each sprint. Counting the number of stories is enough for them.

https://scrumguides.org/scrum-guide.html#product-backlog

The components of user stories and epics

In the previous video, we introduced user stories and epics. User stories are
short, simple descriptions of a deliverable told from the perspective of the user.
Creating user stories helps the team develop a solution that is always centered
around the user’s needs and overall experience.

You also learned that epics are a collection of user stories. Think of the concept of
user stories in terms of books or films. A story is one single narrative, while an epic is
a set of several related, independent stories. Each story tells a specific chronicle,
while an epic gives a high-level view of the overall arc.

User stories
The driving factor behind every Scrum project is putting the customer first. User
stories are a key component of ensuring that customers are satisfied with the
product. A team writes a user story from the perspective of the user. Not only do
user stories provide insight into what goals the user wants to achieve, but they
enable collaboration, inspire creative solutions, and create momentum by giving the
team a small win when the stories are developed.

When writing user stories, you will need to include the following components:

 User persona. What is your user like? What is their relation to the project?
What goals do they have?
 Definition of Done. This refers to an agreed upon set of items that must be
completed before a user story can be considered complete.
 Tasks. What are the key activities needed to complete the user story?
 Any feedback already provided. If you are adding features to an
existing product and you have already received feedback from customers on a
past iteration, make sure to consider this feedback.

I.N.V.E.S.T.
Recall from the video that your user stories should meet the I.N.V.E.S.T. criteria:

 Independent: The story’s completion is not dependent on another story.

 Negotiable: There is room for discussion about this item.
 Valuable: Completing the user story has to deliver value.
 Estimable: The Definition of Done must be clear so that the team can give
each user story an estimate.
 Small: Each user story needs to be able to fit within a planned Sprint.
 Testable: A test can be conducted to check that it meets the criteria.
Let’s imagine you are working on a project for a local library. The library hopes to
launch a website so that customers can read reviews before they check out books
from the branch. The typical template for a user story looks like this: As a <user
role>, I want this <action> so that I can get this <value>.
Therefore, an example user story for this situation might read: As an avid
reader, I want to be able to read reviews before I check out a
book from my local branch so that I know I am getting a book I
am interested in.

Epics
An epic’s purpose is to help manage related user stories. In this post, Mike Cohn, the
inventor of the term “epic” as it relates to Scrum, describes epic as a “very large user
story”—one that could not be delivered within a single iteration and may need to be
split into smaller stories. The team should discuss together and reach a shared view
of how to write and capture their user stories and epics. Keep in mind, epics are just
larger user stories that are there to help organize the project.

Let’s imagine you are creating user stories and epics based on the previous
example. User stories may include customers wanting to read reviews of books on
the website or wanting to add books to their cart. These user stories could fall into
the “website creation” epic.

Another user story could be that customers want to walk into the library and easily
find the non-fiction section. This would fall under the “organization of the physical
space” epic.

So rather than those various user stories appearing in a list together, they are
organized into sections, or epics.
 Testing 1234

It’s important to note that while the Product Owner can write user stories and epics, a
Developer can also write them as long as the Product Owner remains accountable
for the Product Backlog item.

Key takeaway
Epics allow you to keep track of large, loosely-defined ideas, while user stories are a
much smaller unit of work, inspired directly from the end user or customer. Both user
stories and epics help teams ensure they are delivering value to the customer.

Scenario

Review the scenario below. Then complete the step-by-step-instructions.

Imagine you are overseeing the development and launch of Virtual Verde, Office Green's new
product line. Virtual Verde’s mission is to make working from home more enjoyable by offering
desk plants for home office use. New customers recently received the first batch of plants.

As a next step, your team had planned to introduce new product offerings to the Virtual Verde
catalog—starting with Bonsai trees. However, a customer survey discovered that 70% of the new
customers had difficulty caring for their plants. Many of the plants wilted and died within a month.
This information inspired the team to develop new offerings and companion products to help new
owners care for their plants.

From the survey, Office Green learned that they can create value for their customers by making it
easy to:

 Find out which plants are easiest to care for

 Access care instructions easily
 Have the right tools to care for their plants
 Remember when to water their plants
 Get expert help and advice quickly
 Have a hassle-free way to return their orders

You will work with your team to create user stories that will help them build solutions to address
these customer needs, and add them to the Product Backlog. Your team has already added
Bonsai tree user stories to the Backlog, but the new plant care stories have now become the top
priority.

Assessment of Exemplar
Compare the exemplar to your completed approach plan. Review your work using
each of the criteria in the exemplar. What did you do well? Where can you improve?
Use your answers to these questions to guide you as you continue to progress
through the course.

Note: Your user stories, titles, and acceptance criteria will differ in some ways from
the ones below. That’s okay--the most important thing is that your user stories are
concise, actionable, and deliver value to the user role.

Let’s examine the exemplar:

1. Low-maintenance options: The user story follows the correct structure

and meets the I.N.V.E.S.T. criteria: “As a potential customer, I want to find out
which plants are easiest to care for so that I can purchase low-maintenance
options.” The acceptance criteria enable customers to sort plants by difficulty on
the website and find out which plants have similar care needs.
2. Plant care tips: The user story follows the correct structure and meets the
I.N.V.E.S.T. criteria: “As a plant owner, I want to access care instructions easily
so that I can keep my plant alive longer.” The acceptance criteria enable
customers to consult a plant care leaflet and sign up for monthly emails with
seasonal tips.
3. Plant care tools: The user story follows the correct structure and meets the
I.N.V.E.S.T. criteria: “As a plant owner, I want to have the right tools to care for
my plant so that I can keep it healthy and beautiful.” The acceptance criteria
enable customers to purchase plant care starter kits or buy tools individually.
4. Watering reminders: The user story follows the correct structure and
meets the I.N.V.E.S.T. criteria: “As a plant owner, I want to remember when to
water my plants so that I don't under- or overwater them.” The acceptance
criteria enable customers to sign up to receive watering reminders and purchase
reminder stickers for their calendars.
5. Expert help and advice: The user story follows the correct structure and
meets the I.N.V.E.S.T. criteria: “As a plant owner, I want to get expert help and
advice quickly so that I know what to do if my plant gets sick.” The acceptance
criteria enable customers to access live chat support and call phone support
during extended hours.
6. Return policy: The user story follows the correct structure and meets the
I.N.V.E.S.T. criteria: “As a customer, I want a hassle-free way to return my order
so that I can be sure I have the right plant for me.” The acceptance criteria
enable customers to easily find credit and return information on the website and
ship their returns with a pre-printed label.
Finally, because the stories all relate to helping customers care for their plants, they
all belong to an epic titled “Plant Care Initiatives.”

Apply what you’ve learned using Asana:

 In addition to spreadsheets, many Scrum teams use more advanced project
management tools and software to manage Scrum events and related processes.
These tools can help you and your team stay organized, save time, and streamline
tasks. Continue to the next course item to learn how to complete this activity using
Asana, a work management tool that helps teams organize their work all in one
place. Then, in an upcoming activity, you’ll be able to apply what you’ve learned in
Asana yourself.

Many organizations adopt similar work management tools, so familiarizing yourself

with the various options will help set you up for success. Ready to get started? Head
to the next course item to begin.

Step-by-Step Instructions

Step 1: Log in to Asana or create a new account

This activity involves some Asana Premium features. You will not be able to complete Steps 6
and 7 without an active Premium trial or Premium account.

If you don’t have an Asana account, you can create one for free here. When you sign up, your
free 30-day Premium trial will start automatically. If you signed up for Asana in an earlier course
and are still within the 30-day trial, you can log in to that account to access Premium features.

If you already have a free Asana account, or your free 30-day trial has ended, you can create a
new account to start a new trial and access Premium features for this activity.

You’ll be prompted to create a project as part of the sign-up process—you can create one for
anything you might be working on.

Step 2: Access the Asana Sprint Planning template

1. From the Asana Home screen, go to Recent Projects and select New Project.
2. Then choose Use a template to access the template library.
3. Select the “Sprint Planning” template from the General Templates list. (If you can’t find the
“Sprint Planning” template, go to Type and select Product.)
4. Select Use Template.
5. Give your project a title. (The default name will be “Sprint Planning.” You can keep this title or
give it a different name. You also have the option to adjust your Team and Privacy settings, but
you don’t need to change them for this exercise.)
6. Finally, select Create project to launch your new project in Board view, which resembles and
works like a Kanban board.
 Note: If you can’t find the “Sprint Planning” template in Asana, you can access it directly here.
Then complete steps 4-6 above to create your project.

Step 3: Add user story titles to the “Backlog” column

Add user story titles to the backlog column as tasks. To do this, select +Add task and enter a
user story title in the task card. Each user story title should have its own card.

You can enter your user story titles from the last activity or use the ones from this list:

1. Low-maintenance options
2. Plant care tips
3. Plant care tools
4. Watering reminders
5. Expert help and advice
6. Return policy

Step 4: Enter six user stories (one story per task)

Click on a task to open its task detail pane. Find the “Description” field and add a user story to
the task description. As a reminder, each user story should follow this construction: As a <user
role> I want <this action> so that I can <get this value>.

You can enter your user stories from the last activity or use the ones from the list below:

1. As a potential customer, I want to find out which plants are easiest to care for so that I can
purchase low-maintenance options.
2. As a plant owner, I want to access care instructions easily so that I can keep my plant alive
longer.
3. As a plant owner, I want to have the right tools to care for my plant so that I can keep it healthy
and beautiful.
4. As a plant owner, I want to be reminded when to water my plants so that I don't under- or
overwater them.
5. As a plant owner, I want to get expert help and advice quickly so that I know what to do if my
plant gets sick.
6. As a customer, I want a hassle-free way to return my order so that I can be sure I have the right
plant for me.

Step 5: Add acceptance criteria as subtasks

Add two pieces of acceptance criteria and add them as subtasks for at least three of the user
stories you entered. To create a subtask, click into a card to open the task detail pane. Select
Add Subtask toward the bottom of the pane (you may need to scroll down to find the Add
Subtask button).
 You can add your acceptance criteria from the last activity or use the ones from the list below:

Low-maintenance options

 Ability to sort plants by "beginner," "intermediate," and "advanced"

 Ability to search for plants with similar care needs

Plant care tips

 Receive plant care leaflets with each order

 Option to sign up for monthly emails with seasonal care tips

Plant care tools

 Can purchase plant care starter kits

 Option to buy partial kits or single tools

Note: Once you close the task detail pane, you can expand subtasks in each card by clicking the
number in the lower-right corner.

Step 6: Add a custom field for epic title

Finally, create a custom field for your epic title.

1. In Board view, click Customize near the top-right corner of your board, and select Add Field.
2. Type “Epic” under Field title. The Field type should be “Drop-down.”
3. Rename “Option 1” with your epic title (e.g., “Plant Care Initiatives”). You can delete “Option 2.”
4. Select Create Field.

Step 7: Add user stories to your epic

To assign a user story to an epic, open its task detail pane. Then select an epic from the
dropdown next to “Epic.” You can also assign user stories to epics from List view by selecting an
epic from the dropdowns in the “Epic” column.

When you click on a card, your Asana project should resemble the screenshot below:
Agile effort estimation techniques
There are all kinds of techniques to use when estimating effort in an Agile way.
Effective relative effort estimation leads to successful and predictable sprint
outcomes, which leads to a successful project overall. Generally speaking, the main
steps to Agile estimation are the same, even if the specific approach varies. Some
examples of Agile estimation techniques are:

 Planning Poker™
 Dot Voting
 The Bucket System
 Large/Uncertain/Small
 Ordering Method
 Affinity Mapping
Planning Poker™
This particular method is well-known and commonly used when Scrum teams have
to make effort estimates for a small number of items (under 10). Planning Poker is
consensus-based, meaning that everyone has to agree on the number chosen. In
this technique, each individual has a deck of cards with numbers from the Fibonacci
sequence on them. The Fibonacci sequence is where a number is the sum of the
last two numbers (e.g., 0, 1, 2, 3, 5, 8, 13, and so on).

Sometimes, Planning Poker decks also include cards with coffee cups and question
marks on them. The question mark card means that the person doesn’t understand
what is being discussed or doesn’t have enough information to draw a conclusion.
The coffee cup card means that the person needs a break.

The Planning Poker strategy is used in Sprint Planning meetings. As each Product
Backlog item/user story is discussed, each team member lays a card face down on
the table. Then, everyone turns their card over at the same time and the team
discusses the estimates, particularly when they are far apart from one another. By
first hiding the estimates, the group avoids any bias that is presented when numbers
are said aloud. Sometimes, when hearing numbers aloud, people react to that
estimate or the estimator themselves, and it changes what their initial thought may
have been. In Planning Poker, teams can easily avoid that bias.

Dot Voting
Dot Voting, like Planning Poker, is also good for sprints with a low number of Sprint
Backlog items. In Dot Voting, each team member starts with small dot stickers, color-
coded by the estimated effort required (e.g., S=green, M=blue, L=orange, XL=red).
The items or user stories are written out on pieces of paper placed around a table or
put up on the wall. Then, team members walk around the table and add their colored
stickers to the items.

The Bucket System

The Bucket System is helpful for backlogs with many items since it can be done very
quickly. In fact, a couple hundred items can be estimated in just one hour with the
Bucket System. The Bucket System is an effective strategy for sizing items because
it explores each item in terms of pre-determined "buckets" of complexity. Keep in
mind that these buckets are metaphorical; this strategy doesn't require the use of
actual buckets, and instead uses sticky notes or note cards as buckets.

In this technique, the team starts by setting up a line of note cards down the center
of the table, each marked with a number representing a level of effort. Then, the
team writes each item or user story on a card. Each person draws and reads a
random item, then places it somewhere along the line of numbered note cards.
There is no need to discuss further with the team. If a person draws an item that they
do not understand, then they can offer it to someone else to place. Additionally, if a
person finds an item that they think does not fit where it was placed, they can
discuss it with the team until a consensus about a more accurate placement is
reached. Team members should spend no more than 120 seconds on each item.

Large/Uncertain/Small
Large/Uncertain/Small is another quick method of rough estimation. It is great for
product backlogs that have several similar or comparable items.

This is the same general idea as the Bucket System, but instead of several buckets,
you only use three categories: large, uncertain, and small. Starting with the simpler,
more obvious user stories, the team places the items in one of the categories. Then,
the team discusses and places more complex items until each is assigned to a
category.

Ordering Method
The Ordering Method is ideal for projects with a smaller team and a large number of
Product Backlog items. First, a scale is prepared and items are randomly placed
ranging from low to high. Then, one at a time, each team member either moves any
item one spot lower or higher on the scale or passes their turn. This continues until
team members no longer want to move any items.

Affinity Mapping
Affinity Mapping is useful for teams that have more than 20 items in their Product
Backlog.

A best practice is to conduct this technique using sticky notes placed onto a wall,
whiteboard, or table. Each sticky note features a different user story or item. Using
sticky notes allows the team to move user stories around in order to group them by
similar theme, group, and pattern. The team begins by placing one sticky note on the
board. Then, the team takes the next sticky note and discusses whether it is similar
to the first item. Based on the team’s assessment, the second sticky note is placed in
the first group or into its own group.

After all of the items are grouped (there should be anywhere from 3–10 groups total),
the team gives a name to each group that represents the general theme of the items.
Then, the groups are prioritized by importance so that the team knows which items
to tackle first.

Characteristics of effective estimation

Regardless of which technique your team chooses, there are several important
characteristics the techniques share that lead to effective estimation:

 Avoids gathering false precision of estimates. In Scrum, assigning

rough estimates results in more accuracy across the project. Therefore, if the
team focuses on identifying relative estimates—rather than a team having a
lengthy debate about whether a task will take seven or 10 days of work—the
team saves time and avoids potentially missing deadlines.
 Avoids anchoring bias. Many of these techniques (e.g., Planning Poker)
keep the initial estimate private, which allows team members to form an
independent opinion on the estimate before sharing their thoughts with the
team. This prevents a known phenomenon called anchoring bias, where
individuals find themselves compelled to put forth estimates similar to others in
the room to avoid embarrassment.
 Promotes inclusivity. These group estimation techniques not only lead to
better estimates but also help the team develop trust and cohesiveness.
 Leads to effort discovery. Estimating in these dynamic ways can help the
team uncover strategies to get items completed which might otherwise not have
been revealed.

Key takeaway
There are several strategies to enlist when it comes to estimating effort and ordering
your Product Backlog. Any one of these techniques are useful. Choosing a particular
strategy is just a matter of what your team prefers.

T-shirt sizes and story points

In the previous videos, you learned about T-shirt sizes and story points—the two
most common units used to help teams estimate user stories in Agile projects. In this
reading, we will explore the processes of estimating user stories in these units.

As a recap, relative estimation means to compare the effort estimated for

completing a backlog item to the effort estimated for another backlog item. Doing this
instead of trying to determine exactly how long a task will take allows your
comparisons and estimates to be more accurate relative to one another.

T-shirt sizes
At first, T-shirt sizes may seem like a somewhat unusual way to measure an item or
user story. But when you think about assigning estimations to items based on sizes
(e.g., XS, S, M, L, XL, XXL), it is actually very helpful and easy. Some of the benefits
to using this technique are that it is quick, well understood by Agile experts, and a
good introduction for teams who are just learning relative estimation.

So what does the process of assigning T-shirt sizes entail? There are several
specific techniques a team can try, but each generally follows these steps. The
team:

 Agrees on the chosen scale and metrics to be used.

 Identifies at least one anchor backlog item. That item will be assigned a T-shirt
size. Some teams will choose two anchor items—one at the top of the range
and one at the bottom of the range.
 Sorts through the remaining backlog items and agrees on T-shirt sizes for each
of them.

Story points
Using story points as the estimate unit is a little more advanced than T-shirt sizes,
but it is essentially the same concept. This method is good for experienced teams.
When using story points, teams usually use the Fibonacci sequence. As a reminder,
this sequence comes from adding the two previous numbers in the sequence
together. For example, 1 + 2 = 3 and 2 + 3 = 5. The important thing to notice about
this sequence is that, as the list continues on, the numbers spread further apart from
each other. Because of this, story points provide more accuracy and specificity than
T-shirt sizes.

So what does the process of assigning story points entail? There are several specific
techniques a team can try, but the basic steps are the same as with T-shirt sizes.
The team:

 Agrees on the permitted points values. Some teams cap the size at a certain
number, like 21. Some teams decide to jump from 21 to 100 as the next larger
value. This is a team decision.
 Identifies at least one anchor backlog item and agrees to assign it a points
value. Some teams will choose two anchor items, one at the top of the range
and one at the bottom of the range.
 Sorts through the remaining backlog items as a team, agrees on an estimate for
each item, and captures it in the backlog management system.

Best practices
Some best practices, regardless of the technique you use, include:

 Asking the Product Owner questions about the user story or item to ensure that
there is enough information to estimate it.
  Discussing divergent estimates from various team members so that everyone
has a chance to understand how to implement the item.
 Agreeing on the final T-shirt sizes or points value and capturing it in the system.
 If certain items fall into the larger T-shirt size or story points value range,
discussing whether it makes sense to break them down into smaller pieces
before moving on.

Key takeaway
Either of these effort estimation units are effective at estimating your items and user
stories. As a team, it is important to spend the appropriate amount of time deciding
which is best for you. If you are a less experienced team, try starting out with T-shirt
sizes, but more advanced teams should feel free to use either method.

Assessment of Exemplar

Compare the exemplar to your completed adding estimation template. Review your
work using each of the criteria in the exemplar. What did you do well? Where can
you improve? Use your answers to these questions to guide you as you continue to
progress through the course.

Note: Your estimates may vary based on how you interpreted the acceptance
criteria for easy story.

Let’s review the estimations in the exemplar:

As a potential customer, I want to find out which plants are

easiest to care for so that I can purchase low-maintenance
options. Value: $$$. Estimation: 8.

Value is high, since finding the right plants can increase the chances of a new plant
owner’s success. The search and sorting options should take less effort than the
Bonsai Tools, since they won’t involve working with vendors to source items or
materials. The effort is estimated at 8, which is lower than the estimate for the
Bonsai Tools story.

As a plant owner, I want to access care instructions easily so that

I can keep my plant alive longer. Value: $$$. Estimation: 8.

Value is high, since accessible care instructions can make it easier for customers to
keep their plants healthy. As a landscaping company, Office Green already has the
knowledge and resources to make the care leaflets. The effort involved is therefore
closer to the search and sorting options than the Bonsai Tools story, so the effort is
also estimated at 8.

As a plant owner, I want to have the right tools to care for my

plant so that I can keep it healthy and beautiful. Value: $$.
Estimation: 13.

The story brings value to customers because having the right tools can make it
easier for customers to care for their plants. Your team may need to source or
manufacture products, resulting in more effort, coordination, and costs for the
company. Given the resources required, an effort estimation of 13 or higher is
appropriate—similar to the Bonsai Tools story.

As a plant owner, I want to remember when to water my plants so

that I don't under- or overwater them. Value: $$. Estimation: 5.

Watering reminders bring value to customers who have trouble remembering when
their plants need attention. The reminder stickers should take less effort than the
plant care leaflets, so the estimated effort is 5.

As a plant owner, I want to get expert help and advice quickly so

that I know what to do if my plant gets sick. Value: $. Estimation:
8.

The value of this item is lower, since customers are just as likely to search the
internet for ways to cure their plants as they are to contact support. Live chat and
longer phone support hours would be an extension of existing support services.
Therefore, the effort required is 8, which is less than sourcing materials for plant care
kits.

As a customer, I want a hassle-free way to return my order so

that I can be sure I have the right plant for me. Value: $$.
Estimation: 5.

The value of an easy return process is potentially high, since it can help with
customer satisfaction and retention. The effort involved is relatively low, since linking
the FAQ can be done quickly and Office Green has prior experience with shipping
and returns. Effort is estimated at 5.

Apply what you’ve learned using Asana:

As you learned earlier, in addition to spreadsheets, many Scrum teams use more
advanced project management tools and software to manage Scrum events and
related processes. These tools can help you and your team stay organized, save
time, and streamline tasks. Continue to the next course item to learn how to
complete this activity using Asana, a work management tool that helps teams
organize their work all in one place. Then, in an upcoming activity, you’ll be able to
apply what you’ve learned in Asana yourself.
Many organizations adopt similar work management tools, so familiarizing yourself
with the various options will help set you up for success. Ready to get started? Head
to the next course item to begin.

The relationship between Agile and

DevOps
In the last video, we discussed the role of DevOps in Agile at a high level. Many
organizations have begun to embrace and employ this approach. We recommend
reading about the relationship between traditional Agile frameworks and DevOps in
these articles for further understanding:

 How to Combine DevOps and Agile

 Agile vs DevOps: What's the Difference?
 The Convergence of Scrum and DevOps

Scaling Agile
In the preceding videos, we’ve covered how to run a Scrum team of up to nine team
members. But what do you do if your team is larger than that? Or if the size of the
product or solution is so large that multiple teams are required to do the work? In this
reading, we will explore five frameworks that scale the Agile approach to address the
needs of large initiatives or solutions: Scaled Agile Framework (SAFe),
Scrum of Scrums, Large Scale Scrum (LeSS), Disciplined Agile
Delivery (DAD), and the Spotify Model.

Scaled Agile Framework (SAFe)

The most popular scaled framework is the Scaled Agile Framework or SAFe.
SAFe is a Lean-Agile scaling framework that draws heavily on concepts from
Kanban, Scrum, Extreme Programming (XP), DevOps, and Design Thinking
methodologies. SAFe puts the goal of delivering value above all else—the first
principle of SAFe is “take an economic view.” The framework organizes all work and
teams into “Agile Release Trains” based on value streams; for example, sales. The
SAFe framework is mature and provides detailed guidance on all elements of using
SAFe, but some elements are more critical than others. Be sure to check back to the
Agile principles and values in the manifesto to be sure you are preserving agility.

SAFe, like most Agile practices, is founded on a set of core values:

 Alignment: Synchronize the planning and execution of SAFe activities at all

levels of the organization.
 Built-in Quality: Build quality into all stages of solution development.
 Transparency: Make execution activities visible at all levels to build trust
among teams and across the organization.
 Program Execution: Focus on working systems and business outcomes.
 Leadership: Model the values and principles of SAFe.
Read this article to learn more about the core values of SAfe.
Scrum of Scrums
Scrum of Scrums is a technique for integrating the work of multiple, smaller
Scrum teams working on the same project or solution. Coordination among teams is
critical to ensuring the deliverables from each team can be integrated into one larger,
cohesive deliverable.

Scrum of Scrums involves the following elements:

 A group of at least 12 or more people divided into Scrum Teams of five to ten
people each
 Scrum of Scrums meetings, which are held once a week, twice a week, or daily.
These meetings follow the same format as a Daily Scrum meeting but focus on
the Scrum team. In these meetings, you’ll discuss questions like: “What did the
team do yesterday? What problems occurred, if any, that are negatively
affecting your team? What does your team want to accomplish before we meet
again? Is your team blocked from moving forward on any tasks?”
 A Scrum Master or designated “ambassador” for each team that participates
in the Scrum of Scrums meetings and a Scrum of Scrums Master who
focuses on the overall Scrum process across multiple teams
 Sprint Planning, Sprint Review, and Sprint Retrospective meetings
Beyond these very basic guidelines, there is no official framework or methodology to
implement Scrum of Scrums. Scrum of Scrums assumes that teams have a good
working understanding of Scrum and are able to apply the scaling principles to how
they work. Building on this knowledge, they design and iterate their own approach to
coordinate multiple teams working on the same product.

Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) is a framework that aims to maximize the Scrum
team’s ability to deliver value and reduce waste in larger organizations. LeSS grew
out of more than 600 experiments that expanded the practice of Scrum to larger
groups.

LeSS includes ten principles for applying the value, elements, and overall purpose of
Scrum across an organization. These principles were designed to create more
customer- and collaboration-focused teams. LeSS teams prioritize learning,
transparency, and customer needs. The ten LeSS principles are:

1. Large-scale Scrum is Scrum: Apply the values and principles of Scrum to

a larger team.
2. Empirical process control: Inspect, adapt, and learn from experience to
improve processes.
3. Transparency: Ensure clarity and accessibility across a project.
4. More with less: Create only necessary processes, roles, artifacts, and waste
when scaling.
5. Whole-product focus: Think holistically about the product, making sure
that all the parts serve the whole.
 6. Customer-centric: Keep the customer’s needs and values at the heart of
your process.
7. Continuous improvement towards perfection: Improve the product
—and your process—during every single Sprint.
8. Systems thinking: Think about the system as a whole; Don’t get lost in the
details.
9. Lean thinking: Seek continuous improvement, aim for perfection, and
respect people.
10. Queuing theory: Embrace the Lean principles of “flow,’ manage queue
size,” and “minimize multitasking” to keep delivering value.
The LeSS toolkit provides two frameworks—one for up to about 50 people (called
Basic LeSS) and one for 50–6000+ people (called LeSS Huge). More
information on the LeSS frameworks can be found at less.works.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a hybrid approach that combines the
strategies from various Agile frameworks, including Kanban, LeSS, Lean
Development, Extreme Programming, Agile Modeling, and more. DAD guides people
through the process-related decisions that frameworks like SAFe and Scrum of
Scrums leave open. DAD helps you develop a scaled Agile strategy based on
context and desired outcomes.

DAD is organized into four “layers”:

1. Foundations discusses the principles, guidelines, Agile concepts, roles and

team structure definitions, and Way of Working (WoW).
2. Disciplined DevOps ensures that solutions are delivered to customers
effectively and safely, with data and security management always at the
forefront.
3. Value Streams ensures that solutions are aligned with the organization's
business strategy, connecting customers, sales, and portfolio management to
the framework.
4. Disciplined Agile Enterprise (DAE) connects the industry marketplace
with corporate governance and larger enterprise activities.
Project managers wishing to implement DAD can read more about the framework in
this article: Going Beyond Scrum.

The Spotify Model

Another approach you may encounter is the “Spotify Model,” which we discussed in
a previous reading. It is important to note that Spotify’s model is not a true Agile
framework. There is no standard guide on how to implement it. The model began as
a description of how Spotify overcame the challenges of scaling Agile. By focusing
their efforts on culture, team autonomy, communication, accountability, and quality,
they increased their agility over time. Spotify’s approach has had a huge impact on
workflows and team structures across the tech world. Some of the key components
include:
  Squads: Like Scrum teams, Squads are autonomous teams of 6–12 people
working toward the same outcome. All Squads include a coach (similar to a
Scrum Master) and a Product Owner.
 Tribes: When multiple Squads work on the same feature area, they form a
Tribe of 40–150 people. Each Tribe has a Tribe Lead who fosters collaboration
and coordination.
 Chapters: Squads may be autonomous, but specialists (e.g., JavaScript
developers) should still align across an organization. Chapters establish best
practices and, where necessary, set standards.
 Guilds: Any group of people interested in a certain topic can form a Guild,
where people with shared interests can come together as a community.
While some organizations have had success with this model, be aware that it
evolved from Spotify’s already significant Agile experience. It is the product of
extensive introspection and adaptation and draws heavily on the company’s culture
of trust, transparency, and autonomy. Therefore, the value of Spotify’s approach to
scaling is not in team names like Squads and Tribes but in how they developed
practices that supported and served their organizational culture. To learn more about
the Spotify Model, check out this video from Henrik Kniberg.

Best practices for scaling Agile

No matter which framework you choose, it’s important to keep a few basic principles
in mind:

 Treat scaling models like SAFe, Scrum of Scrums, LeSS, etc., as general
frameworks, not instruction manuals.
 Different situations require different solutions. It’s okay to mix and match
elements from multiple frameworks, as long as you apply the principles and
values of the Agile Manifesto.
 Don’t try to scale without prior Agile experience. Going straight from Waterfall to
scaled Agile can be risky without a knowledgeable guide.
 Finally, and most importantly, don’t scale if it isn’t necessary. The larger your
team, the more complex and difficult your project becomes.

Key takeaway
Scaling Agile can be as simple as putting two Scrum teams together into a Scrum of
Scrums configuration or as sophisticated as training an organization of thousands in
the SAFe framework. When you have a large team or a big deliverable that requires
multiple workstreams, think about how you can scale to suit your situation.
Remember that you can modify SAFe, LeSS, and other scaled frameworks to meet
the needs of each project. Make sure your team understands Agile principles before
you try to scale since scaling inevitably introduces more waste and complexity.