05 Agile Project Management

Course overview

This course will explore the history, approach, and philosophy of Agile project management, including the
Scrum framework. You will learn how to differentiate and blend Agile and other project management
approaches. As you progress through the course, you will learn more about Scrum, exploring its pillars and
values and comparing essential Scrum team roles. You will discover how to build, manage, and refine a
Product Backlog, implement Agile’s value-driven delivery strategies, and define a Value Roadmap. You will
also develop the skills to organize the five important Scrum events for a Scrum team, introduce an Agile or
Scrum approach to an organization, and coach an Agile team. Finally, you will learn how to search for and
land opportunities in Agile roles. Current Google project managers will continue to instruct and provide
you with the hands-on approaches, tools, and resources to meet your goals.

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 conveying information to and within a development
team 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.

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 Ikujiro 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. Tribes are
collections of squads that work in a specific area and are meant to have less than 100 people. Chapters
are small groups of people across a tribe that have similar skills and work in the same general competency
area. Guilds are the largest group, comprised of people across the organization who want to share
knowledge, tools, code, and practices.

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.
 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 that people can use to 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 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, that focuses on delivering high-quality product
increments.
For sure, this sounds great!
But what are the characteristics of such a great Scrum team? This article answers that question. It
describes the characteristics and skills of a great Product Owner, Scrum Master, and Development Team.
Product Owner
The Product Owner is responsible for maximizing the product’s value 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
customer’s voice and creates a product vision 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 make decisions related to the product.
Sure, creating support for their decisions might take some time, but swiftly making 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 build the foundation and
walls earlier and therefore prioritize 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 good old-fashioned conversation.
• Knows modeling techniques. A great Product Owner has a backpack full of valuable modeling
techniques. They know when to apply a specific model. Examples are Business Model Generation,
Lean Startup, or Impact Mapping. Based on these models they know 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 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 adds a second dimension to your backlog. This visualization shows
the big picture of the product backlog. Jeff Patton has written 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 they are part of. A product should always be built with its context taken into account.
This includes understanding the organization paying for the development but also being aware of
the latest 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 product roadmap (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 that their 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 their product. They have a
keen eye for opportunities, focus on business value and the Return On Investment and act
proactively on possible risks and threats. Everything with the growth (size, quality, market share) of
the 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. For 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 refinement 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 are involved because it gives them the
opportunity to explain their wishes and desires. The Development Team is able to clarify functional
and technical questions or implications. This approach ensures 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.
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 the situation and context. All that the Scrum
Master does has the purpose of helping people understand and better apply the Scrum framework.
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 by coaching individuals with a focus on mindset and behavior: 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. They understand Tuckman's different stages of team
development: forming, storming, norming, performing, and adjourning. The importance of a stable
team composition is 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. They know 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. They understand 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 them anymore on a daily basis. But due to their proven contribution
they will get asked for advice frequently. Their role has changed from a daily coach and teacher to
a periodical mentor and advisor.
• Let their team fail (occasionally). A great Scrum Master knows when to prevent the team from
failing but also understands when they 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 their 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. They are 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.
They listen carefully to what is said, but also to what isn't said.
• Observes. A great Scrum Master observes their team with their daily activities. They don't have an
active role within every session. The daily Scrum, for example, is held by the team for the team.
They observe 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 formats. This ensures the retrospective will be a fun and useful event for
the team. They know what format is most suitable given the team's situation. Even better: they
support 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 them. They know how to guide without prescribing. They can close the gap
between thinking about doing and actually doing; they can help the team members understand
themselves better so they can find new 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, they prevent them.
Due to their experiences they are able to 'read' situations and hereby act on them proactively.
• Isn't noticed. A great Scrum Master isn't always actively present. They don’t disturb the team
unnecessarily and supports the team in getting into the desired 'flow'. But when the team needs
them, they are 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. They know the strengths, weaknesses, opportunities and risks of every
method/framework/principle and how & when to use them. They try 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. They do
this by inspiring them to unleash their inner potential and showing them the desired behavior. At
difficult times, they show them how to act on it; they don't panic, stay calm, and help the team
find the solution.
• Is a born facilitator. A great Scrum Master has facilitation as their 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.
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 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 Scrum events as
opportunities for conversations. Tobias Mayer describes this perfectly in his book ‘The People's
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 of non-functional requirements such as performance, security, and
scalability. They can explain the (business) value to their Product Owner and customer and thereby
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 can deliver business value in the first sprint.
• Acts truly cross-functional. Great Development Teams not only have a cross-functional
composition, they truly act cross-functionally. They don't talk about different roles within the team
but are focused on delivering a releasable product for every 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 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 honestly and respectfully. They grasp the concept of the 'Situation - Behavior - Impact
Feedback Tool' and therefore 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. This approach ensures 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 doesn’t vary much. They know how
many items they can realize each sprint. Counting the number of stories is enough for them. .
 Product Backlog: The Scrum Guide overview

Product Backlog and Product Goal

In this lesson, you are learning about an important Scrum artifact: the Product Backlog. To recap, the
Product Backlog is an ordered list of what needs to be done to improve a product. It is the single
authoritative source for items the Scrum Team works on. During Product Backlog refinement, items are
broken down and further defined by adding details. These details can vary, but often include such
attributes as description, value, order, estimate, and size.
The Product Goal is the long-term objective for the Scrum Team, and it is included in the Product Backlog.
The rest of the Product Backlog defines what tasks will fulfill the Product Goal.

Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single
source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for
selection in a Sprint Planning event. They usually acquire this degree of transparency after refining
activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog
items into smaller more precise items. This is an ongoing activity to add details, such as a description,
order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may
influence the Developers by helping them understand and select trade-offs.
Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team
to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to
define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or
customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one
objective before taking on the next.
Sprint Backlog
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the
Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work
that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.
Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have
enough detail that they can inspect their progress in the Daily Scrum.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the
Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also
creates coherence and focus, encouraging the Scrum Team to work together rather than on separate
initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the
Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different
than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog
within the Sprint without affecting the Sprint Goal.
Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior
Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value,
the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint
Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the
end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality
measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work
was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done,
it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for
future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams
must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a
Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams
working together on a product, they must mutually define and comply with the same Definition of Done.
 The elements 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 elements:
• 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.
 Create Product Backlogs using work management tools

Workers from across a variety of industries lose countless hours to “work about work.” This is the time
wasted on searching for information, switching between apps, and holding status meetings. Work
management tools are designed to reduce wasted time by empowering project managers to focus on
project planning, team alignment, and resource allocation. Many organizations use these types of tools to
manage everything from simple projects with small teams to complex projects with multiple stakeholders.
As a project manager, you may encounter different work management tools that can streamline your
team’s work and maximize your productivity throughout your career. Luckily, many of these tools have
similar functions. In this reading, you will learn about creating Product Backlogs using one of these work
management tools. This example will showcase these skills using Asana; however, you can also apply
these concepts to other tools!
Work management tools and Product Backlogs
As you've already learned, a Product Backlog is one of the most important Scrum artifacts and functions
as the single authoritative source for project tasks. It contains all of the features, requirements, and
activities associated with the project deliverables in one place.
Since it's a living artifact, you need to update and reorganize the Product Backlog according to the product
owner’s evolving project needs. Tools like Asana can automate some of this work for you. Many
organizations encourage these types of tools to manage complex projects with multiple stakeholders.
Note: If you would like to follow along, you can create an Asana account 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. You can also
access free tools like ClickUp or Monday to explore their interfaces!
Leverage templates
In the activity Create a Product Backlog, you built a Product Backlog for the Virtual Verde Project. In this
reading, you will explore how to build the same Backlog using projects, tasks, subtasks, and custom fields
in Asana. One of the great things about tools like Asana is that they have a lot of helpful templates for all
kinds of projects. When you choose to create a new project, you can select the appropriate template from
the library and customize it to fit your needs.
In this case, the Sprint Planning template from Asana’s library is a great option for creating a Product
Backlog.

After creating a project, you’ll be directed to the Board View where you can start adding project details.
Board View can help you track your team’s sprint plans, similar to using a Kanban board. Most teams make
projects at the beginning of each sprint and track their work through each stage to make sure they know
where their sprint work stands. In this template, those stages are represented by sections, which appear
as column headers in the board view.
Add user story titles to the “Backlog” column
After creating the project, you can enter User Story Titles by adding tasks to the Backlog column for the
Virtual Verde project.

In this case, the same user story titles from the last activity have been added:
1. Low-maintenance options
2. Plant care tips
3. Plant care tools
4. Watering reminders
5. Expert help and advice
6. Return policy
You can also add the User Stories in the task details. For example, the User Stories from the previous
activity:
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.
Add acceptance criteria as subtasks
Because the user story titles were entered as “tasks” in this template, the acceptance criteria can be
added as subtasks.
Here are some examples for acceptance criteria from the previous activity:
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
Add a custom field for epic title
You can also add a custom field for the Epic title. Custom fields let you add additional details to the tasks
in a project— you can think of them like tags, or columns in a spreadsheet.
From the Board View, you can add fields from the Customize menu.
Since all of these stories are part of the same epic, you can update the epic for all the user stories at once.
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.
For more information, and to practice using Asana for Agile and Scrum processes, check out Asana for
Agile and Scrum.
Key takeaways
This was just one example of how you can use work management tools to create Product Backlogs. As
you’ll discover, there are many different tools designed to help you keep track of all of your to do’s, and
ensure that you and your teammates are always clear about who’s responsible for what and when it
needs to get done. Understanding the concepts that drive these tools will allow you to make the most of
them, whatever tool your organization uses!

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

Add effort estimates using work management tools

Previously, you discovered that work management tools can help you focus on project planning, team
alignment, and resource allocation, and you even explored how tools like Asana can help you create a
backlog. You also learned that adding estimates to backlog items informs planning practices by helping
you and your team understand how much effort it will be to finish each item or user story.
In this reading, you’ll review how to use work management tools to add effort estimates, similar to the
previous activity where you updated the Virtual Verde Product Backlog manually. This example will
showcase these skills using Asana; however, you can also apply these concepts to other tools!
Work management tools and effort estimates
It isn’t always easy to estimate how much time it will take to complete a task. We often underestimate the
time it takes to do something, which can create issues with expectations, deadlines, and budgeting on big
projects.
To avoid this, you can practice relative estimation by comparing the effort of that task to the effort for
another task to create the estimate instead of trying to determine exactly how long it will take.
Note: If you would like to follow along, you can create an Asana account 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. You can also
access free tools like ClickUp or Monday to explore their interfaces!
Upload a CSV file to create a new project
In the activity Add estimation, you updated the Virtual Verde Product Backlog by adding effort estimation
to user stories and acceptance criteria. You can apply the same concept to the work management tools
you’re using! Previously, you learned about using templates in tools like Asana in order to create new
projects, but you can also upload a CSV file to input project details. This is a great option for moving your
workflow out of a spreadsheet software like Excel or Google Sheets directly to the work management tool
your team uses. That way you can get started right away on any project.
From your dashboard, you can click the Create button to create a new project. Instead of choosing the Use
a template option, you can select Import spreadsheet to upload a CSV file. You’ll be prompted to name
the project—in this case, the project will be called Virtual Verde Backlog.

After uploading the CSV file of your choice, you’ll be able to preview the project to ensure that the upload
was successful before finalizing the project.

Add the effort estimation

When you import the CSV file, Asana automatically generates some custom fields for your Backlog: in this
case, it has added “Epic,” “Value,” and “Estimate (Story Points).”
You can type directly in the “Estimate” column to add estimates to your Backlog items. In this case, it’s the
same estimates from the last activity:
• Low-maintenance options: 8
• Plant care tips: 8
• Plant care tools: 13
• Watering reminders: 5
• Expert help and advice: 8
• Return policy: 5

Sort user stories

Depending on how you want to organize the stories in your backlog, you might choose to sort by any of
the custom fields. This allows you to customize the organization of your backlog.
In this case, the project will be sorted by “Value.” After sorting, you can select the three dots at the upper-
right corner of the Backlog and choose Save layout as default. This will make sorting by "Value" the default
layout for this project. Once you’ve organized your user stories, you can switch to Board view to work with
them in a Kanban-style Backlog. Finally, to make Board view the default layout, just select the three dots
at the upper-right corner of the Backlog and choose Save layout as default.
Key takeaways
The beauty of using a tool like Asana to manage a Backlog is how quickly and easily you can convert your
plans into action! You can give each user story an assignee and a due date to make it clear who’s
responsible for what, and when it needs to get done. Then, you can keep everyone on the same page by
publishing weekly status updates, highlighting accomplishments, progress, and blockers.

The Sprint: The Scrum Guide overview

As a recap, please read this overview of the Sprint taken directly from the 2020 Scrum Guide:
The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately
after the conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review,
and Sprint Retrospective, happen within Sprints.
During the Sprint:
• No changes are made that would endanger the Sprint Goal;
• Quality does not decrease;
• The Product Backlog is refined as needed; and,
 • Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at
least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid,
complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning
cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short
project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven
useful, these do not replace the importance of empiricism. In complex environments, what will happen is
unknown. Only what has already happened may be used for forward-looking decision making.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the
authority to cancel the Sprint.

Create and manage Sprints using work management tools

As you have learned, sprints provide the rhythm for the team. They create opportunities for you to get
feedback more quickly, encourage team collaboration, and provide greater focus. They are like mini-
projects with their own planning, execution, delivery, closing, and retrospective.
By planning sprints using work management tools, teams can have full clarity on Sprint Plans, milestones,
launch dates, and Backlog, with work efforts and communication together in one place. In this reading,
you’ll discover how to plan a sprint using a work management tool. This example will showcase these skills
using Asana; however, you can also apply these concepts to other tools!
Note: If you would like to follow along, you can create an Asana account 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. You can also
access free tools like ClickUp or Monday to explore their interfaces!
Add a custom field for sprints
In the activity Create a Sprint Plan and Sprint Backlog, you planned the first Sprint for the Virtual Verde
project. Here, you will learn how to recreate planning that Sprint using Asana. In this reading, each item in
the Virtual Verde Backlog will be prioritized and scheduled for an upcoming sprint. To do that, you can add
a custom field for Sprints, which will allow you to easily find out which Sprint each task is scheduled for.
You can open the Customize menu by clicking the button in the top right corner.
You can select Fields from the Add section to add a Sprint field. You can also add options for the Current
Sprint and the Next Field in order to plan ahead for future sprints, too.

Assign items to the Sprint Backlog

After creating the Sprint field, you can assign items to the Sprint Backlog for the first two Sprints. For this
step, it’s recommended that you switch over to the list view, since it’s easier to see all your tasks at once.
You can assign items to the Current Sprint or Next Sprint using the drop-downs in the Sprint column.
Finally, you can add a due date for the “Current Sprint” items under the “Due date” column
There’s so much more you can do with Sprint planning in Asana! You can automate repetitive steps by
adding rules, plan and visualize your team’s work using Timeline view, or create a custom template so you
can easily launch a new Sprint-planning project without starting from scratch. Check out this article on
Sprint planning in Asana for inspiration!.
Key takeaways
Sprint planning is just one of the ways tools like Asana can help you manage team projects and tasks. From
hitting goals and deadlines, to tracking progress and troubleshooting, automating and streamlining work,
and tying all your workstreams together in one place, work management tools have a lot of resources to
make sure all your projects are set up for success.

Releasable Increment versus Minimum Viable Product

You have learned that the Product Increment is what is produced after a given Sprint and is considered
releasable. The Scrum Guide states that “An Increment is a concrete stepping stone toward the Product
Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all
Increments work together. In order to provide value, the Increment must be usable.”
Potentially releasable product increment
Potentially releasable (or shippable) Product Increment is a handy way for teams to think about the
desired result of a Sprint. The goal for every Sprint is to result in a completed, tested, ready-to-ship
addition to the product or solution. This doesn’t mean the product will actually ship to customers—that is
why they use the word “potentially.” Consider, for example, building an application for finding and
adopting pets. Three features on the product backlog could be:
1. Presenting information about available pets
2. Rating potential matches based on adopters
3. Allowing user to contact the adoption center

It doesn’t make sense to ship any one of those features in isolation, but finishing a potentially releasable
Product Increment is helpful because it enables the team to see one feature in its entirety rather than to
work on bits and pieces of all three features with none of them actually completed. With a potentially
releasable Product Increment, you will create a complete, working, tested implementation of one feature
in a single sprint.
Having a potentially releasable Increment also allows the team to get early feedback on the product,
ensure that the work is high quality, and have the opportunity to respond to change. You should always
focus on a potentially releasable product increment as your sprint goal.
Definition of Done
A related term is the Definition of Done. The Definition of Done is a formal description of the state of the
potentially releasable Product Increment and what it means when it meets the quality measures required
for the product. It is the team’s agreed-upon requirements for any backlog item that is considered “done.”
In software projects, teams often decide that “done” means the software has been completed, reviewed,
and has passed testing. In a non-software project, a Definition of Done may be a document including a
legal review with approval or a formalized closeout report. The important part of figuring out your team’s
Definition of Done is to have an explicit, shared understanding of what being “done” entails.
But how do you know when a solution is shippable or releasable? In a Scrum Team, it is ultimately the
decision of the Product Owner to ensure there is value before releasing an item. To determine this, they
may consider a few things:
 1. Is the increment complete?
2. Will it bring value and does it meet quality measures? Has it been well-tested?
3. Is it usable by the end user? Can we use their direct or indirect feedback to improve future
versions of the product?
Comparing Releasable Product Increment to Minimum Viable Product
As you learned in the previous video, a minimum viable product (MVP) is a version of a product with just
enough features to satisfy early customers. Eric Ries, an entrepreneur and author, coined the term in this
guide and defined an MVP as “that version of a new product which allows a team to collect the maximum
amount of validated learning about customers with the least effort.” In other words, gathering insights
from an MVP enables quicker feedback from users than developing a full-featured product that may not
be 100% tested or secure. Some examples of an MVP could be a landing page for your website or a “buy
now” button that doesn't do anything other than register that someone has clicked it. A minimum viable
product is a package of features that may take several sprints to develop, but every sprint’s goal is to
produce a product increment. To differentiate between a potentially releasable increment and a MVP,
let’s take our example of the online pet adoption app and the three features we discussed previously. We
noted that each of these features on their own wasn’t a useful release of the solution. However, the
Product Owner may decide that the MVP for this user experience is to implement these three
requirements for cats only. By reducing the scope of the MVP, the Product Owner is able to release the
solution into the marketplace and collect feedback from the users who wish to adopt cats. This feedback
will be valuable not only for the cat adoption process but for any type of pet adoption in future iterations
of the product.
Key takeaway
So can a releasable increment be an MVP? Yes! Does it always have to be an MVP? Not necessarily. A
Scrum Master or Product Owner is always making sure that the team is building potentially releasable
increments of the solution or product. Then, the Product Owner uses those product increments and
business insights to determine what will make up a valuable and viable release of the product to their
customers. This is based on both user value delivered and the ability to gather feedback that will
continuously improve the product.

Sprint Retrospectives: Pitfalls and best practices

Throughout this program, we have discussed retrospectives. Retrospectives are an integral aspect of
project management, especially true when it comes to working in Scrum. As we mentioned in the
previous video, retrospectives are one of the five Sprint events in Scrum. In this reading, you will learn
some best practices to implement and pitfalls to avoid when conducting Sprint Retrospectives.
Sprint Retrospectives
As a refresher, retrospectives are workshops or meetings that give project teams time to reflect on a
project and brainstorm potential future improvements. In the Scrum framework, Sprint Retrospectives
occur at the end of each Sprint, which is usually every one-to-four weeks.
Sprint Retrospectives are a key practice that supports the Scrum theory and values. They are a critical
moment to inspect and adapt to the outcomes produced within the Sprint timebox. Retrospectives occur
much more often in Scrum than in traditional project management, so it is important to consider some
best practices and pitfalls to avoid to help make them engaging and productive for the entire team.

Pitfalls
• Avoid too many gimmicks. There are many fun games and exercises that can be used by a Scrum
Master when facilitating a Sprint Retrospective. However, not all teams enjoy this style. Consider
using these exercises only occasionally or when the team asks for new ways of doing
retrospectives.
• Try not to only focus on the negative. Not only is it necessary for the team to recognize what’s not
working well, it is also important to highlight where they exceeded expectations. This ensures that
the team both avoids failures and repeats successes as well.
• Avoid changing processes after each retrospective. It is okay to keep a new process in place for a
few Sprints before deciding whether it was useful or not. You can always make note of
opportunities for change, but try to wait a few Sprints before implementing new changes.
Best practices
• Ask open-ended, probing questions. Ask questions that require thoughtful discussion rather than
a yes-or-no answer. For example, ask, “How could we have better achieved our Sprint Goal?”
rather than “Did we achieve the Sprint Goal?””
• Consider diverse styles of communication and participation. Make it easy for all team members
to contribute their ideas and feedback. For example, not everyone feels comfortable speaking up
in a large group. Try things like starting the retrospective with silent reflection by journaling or
putting the team into pairs before starting a larger group conversation.
 • Cover the many aspects of the Sprint when conducting a retrospective.
1. The productivity and efficiency of the team
2. The scope and understanding of the definition of done
3. Communication and interactions within the team
4. Stakeholder communication
5. Progress towards more long-range release plans
• Consider reflecting periodically on Scrum theory and values by asking specific questions. For
example, ask, “How could the team become more transparent?” or “How did we abide by our
Scrum values in this Sprint?”

Interpreting velocity: Dos and Don'ts

In the previous video, we defined velocity as “The measure of how many points the team burns down in a
given Sprint on average.” Velocity measures the amount of work a single team can be expected to
complete during an iteration. When we refer to story points, we are referring to a unit of measurement
that expresses the estimated effort required to implement that Product Backlog item. These story points
are calibrated and decided on by the team.
Calculating velocity
As described in the video and readings, estimating effort can be done in a variety of units. Most often in
Agile teams, story points or T-shirt sizes are used to estimate effort. If you use T-shirt sizes, your team will
map those sizes to a numeric value for the purpose of calculating a team velocity.
When your team begins running Sprints or iterations, they won’t be able to accurately determine velocity
because they will have no historical basis on which to calculate an average number of points completed in
a Sprint. In their very first Sprint, your team will make a rough guess as to how many items they can
complete just to get started. Once a few Sprints have been completed, your team will have a good
measure of their velocity, and they will use that number to determine which items to include in their
Sprint Backlog. This should be easy to do if your team has a properly prioritized and estimated backlog to
work from. As you will recall from the videos, this process is called backlog refinement.
Using velocity for good
When interpreting velocity, it is important to keep a few things in mind. You may feel inclined to share
velocity with members outside of your team or to use velocity as a performance or comparison metric.
You may also feel inclined to use it to determine a projected delivery date. However, some Agile experts
warn against these practices. Let’s discuss why.
Velocity can be helpful for individuals outside of the Scrum team, but when sharing it with non-team
members, be very careful. Since velocity is different for every team, a stakeholder may not have enough
context to interpret it. Be sure to share relevant supporting materials to help add context. A good example
of this is sharing the velocity with a corresponding date range and visualization that indicates trends over
time. There may be dips and spikes in velocity that draw insights and encourage improvements in future
projects.

It is natural for individuals to want to quantify performance through data, but it can be detrimental for a
team to feel that kind of pressure within their Sprints. There may be executives, sponsors, or stakeholders
that want to use velocity as a performance metric, but this will only hurt the team by encouraging tactics
like intimidation. If the team is worried about their velocity making it seem like they are underperforming,
the team’s culture can become harmed as a result.

If you are leading a few different Scrum teams, you may be tempted to compare the two teams’
productivity based on their velocity. You may have the impulse to check which teams are completing the
most story points per iteration. However, the weight of different story points is subjective because they
are created by the team. One team may consider a story to be five points, but another team might
consider it to be closer to three points. Therefore, judging productivity solely on velocity isn’t accurate or
fair. Additionally, velocity is not a measure of value. One team’s velocity might differ from another team’s,
but this variability is fine as long as both teams are delivering value to your stakeholders.
Using velocity to estimate the delivery date of a project spanning numerous Sprints can be tricky. Velocity
can be used as a pressure point by external stakeholders who want to set a date for their product launch.
Velocity can also create false expectations and a harshly competitive culture when the team doesn’t hit
the estimated dates. Projecting deliverable dates is harmful because it can take a team several Sprints to
really understand what they are capable of delivering in each iteration. Also, if you map out too many
dates in advance, you aren’t able to account for the changes and issues that will arise. Therefore, make
sure you are being careful not to use the estimated delivery dates as commitments.

Product roadmaps: Benefits, pitfalls, and best practices

As you learned in the previous video, roadmaps are an important part of any long-running project. In this
reading, we will summarize the benefits of and best practices for developing a product roadmap, as well
as highlight some of the pitfalls you might encounter.
You may see different types of roadmaps as you continue your project management career. Each team or
company may interpret the roadmap slightly differently. Here are some of the various types:
• Project roadmap
• Product roadmap
• Value roadmap
• Lean roadmap
• Agile roadmap
Roadmaps are often represented visually and many try to fit the roadmap on one page so that reviewers
can notice the big picture of the product timeline.
The benefits of developing and maintaining a product roadmap are numerous:
• Clarifying the sequence of deliverables
• Showing teams how their efforts relate to the north-star vision. In other words, their ultimate
goal.
• Showing stakeholders the incremental value that will be achieved over the course of the project
(rather than reviewing it as one big delivery at the end)
• Helping stakeholders roughly understand the layout of the work behind the deliverable
There are also some pitfalls around roadmaps to avoid:
• Letting stakeholders think the roadmap is set and unchangeable. This may cause stakeholders to
impede teams’ ability to adapt in response to new information, as well as put a lot of pressure on
teams to achieve deadlines no matter what it takes.
• Spending too much time fine-tuning delivery dates versus keeping them rough and improving
specificity as the dates get closer
• Putting all the work into creating the roadmap rather than producing the deliverables
Here are some best practices to help you get the most from your roadmaps:
• Make it highly noticeable to the team and refer to it frequently.
• Clearly indicate the highest priority items.
• If possible, clearly indicate the highest value items.
• Make it visible to your wider stakeholder group so that they can use it for their planning.
 • Conduct regular reviews of the roadmap with sponsors, stakeholders, and the team to ensure that
it is still providing the blueprint for the project.
To learn more about some best practices for building product roadmaps, check out this article: Product
Roadmap First Principles
Key takeaway
Roadmaps are important for any well-managed project, but they are especially useful to Agile teams.
Having a shared roadmap about what the team is delivering over a longer time period is an important way
to connect the work that the team does on the sprints with the broader vision for the project. This helps
the team stay motivated through the rough patches and leads to a great sense of accomplishment as
roadmap deliverables are achieved.

Responding to change over following a plan

As we learned in the beginning of this course, Agile dedicates one of its four values to “Responding to
change over following a plan.” This reading aims to clarify some important considerations when
implementing a change to the release plan.
The best way to think about changing your plan is to break it down into three stages:
1. Identifying a needed change
2. Deciding to make the change
3. Implementing the change
Step 1: Identifying a needed change
First, how do you know if your plan needs to be changed? Here are some aspects of your project that may
be candidates for change: scope, time, and costs (or resources). As we previously learned, these are called
the “triple constraint,” and they provide a great framework for evaluating change in Agile and traditional
projects.
• In Agile, scope refers to the contents of the product roadmap, the items in the Product Backlog,
the intended deliverables of the project, and the intended users or customers. This is the “what”
of the project.
• Time refers to the elements of time or layout of the deliverables over a period of time. This could
include the product roadmap timeline, release schedule, or even the Sprint duration. This is the
“when” of the project.
• Costs or resources refer to the makeup of the Development Team, project managers, and product
owners, and other “business people” as well as the equipment available to create the deliverable.
This is the “how” of the project.
Agile projects are open to change in any of these three areas, and a needed change could be identified by
any project stakeholders, including the Product Owner, Project Manager, Scrum Master, or the
Development Team themselves. Sources of identified changes could include:
• Customer feedback on early prototypes results in new features and some deleted features (scope
change)
• Sprint Retrospective identifies an area of understaffing (cost or resource change)
• Critical project dependencies or deliverable dates have shifted, resulting in a change to the project
roadmap (schedule or time change)

Step 2: Deciding to make the change

Next, how do you decide to actually make the change? There are many decision-making models available
to reference. Here are the basic steps involved in most of these models:
• Identify the “decider.” It is best to have a single person—generally the Product Owner or a senior
stakeholder—in the role of decider to ensure consistency and accountability.
• Develop and share what factors are important to the decision, and gather supporting data that
will help the decider make the decision.
• Openly discuss the benefits and costs of the decision. Identify areas of uncertainty and capture
assumptions.
• Document the decision.
Step 3: Implementing the change
Once changes are approved, it is important to do several things:
• Document the change and decision-making process. Include meeting notes, pros/cons lists,
assumptions, and data that went into making the decision to change the project.
• Capture the change in any affected artifacts. Update any roadmaps, Product Backlogs, staffing
plans, and integration dates, and include a reference to the source of the change so that
stakeholders can refer back to it. Consider using revision labels or dates on affected documents like
 “version 1.2” or “updated on December 20th” so that the team can clearly recognize that the
document has changed.
• Share the change with all affected stakeholders. You can do this through many types of forums: in
person at meetings, in documentation and meeting notes, and through email announcements.
• Monitor the change for a certain amount of time. This ensures that the team is supportive and
aware of the change.
If the change was not approved during the decision stage, you should still document the information and
logic used to make the decision. You may even consider putting a change on hold while you wait for more
information to make the decision with higher confidence.

The influencer change framework

In the previous video, we learned how to apply organizational change management techniques to your
team in Agile or Scrum. In this reading, we will learn about the influencer change framework developed
by Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan, and Al Switzler in the book
INFLUENCER: The New Science of Leading Change, which explores the power of influence in facilitating
organizational change.
What does it mean to be an influencer?
These days, when we hear the word influencer, some might think of social media stardom. But being an
influencer is bigger than getting “likes”—it is about someone’s ability to lead and influence others to
change their behaviors, hearts, and minds to produce meaningful, sustainable results. As a project
manager, you will be asked to lead efforts that require this level of change, and applying this model can
lead to a big impact.
To influence is different than to persuade. Persuasion is short-term, while influence is lasting. In order to
have real influence, you need others to trust you, consider you an authority, and have confidence in your
decisions. As a project manager in Agile projects, you may use influence to facilitate organizational change
or to get a team to try a new tool, process, or technology. When facilitating organizational change,
influence is the difference between temporary changes in behavior and deep change in culture and
values.
Three keys to influence
The three keys to influence, as researched by the authors of this model, are to clarify measurable results,
find vital behaviors, and use the six sources of influence. Let’s break each of these down.
Clarify measurable results
You can’t influence others to change until you know what you want, why you want it, and when you want
it. You may recall that effective results are specific, measurable, achievable, relevant, and time-bound
(S.M.A.R.T). When setting goals for a project, remember to ask yourself what the “why” entails. Are the
results specific and measurable? Is it what you intended? Is it time-bound? Also, make sure the measures
are visible and transparent to the entire team throughout the change.
Find vital behaviors
A vital behavior is the action an individual takes at a pivotal moment in the context of the change they are
seeking. For example, if a member of the Development Team is seeking to increase involvement of the
Product Owner throughout the development process, they might exhibit a vital behavior when they have
just finished mocking up a new feature. Instead of just continuing on to the next item on their to-do list,
they might send an email to the Product Owner to review their work and provide feedback. By choosing to
include or exclude their Product Owner at a pivotal moment, the developer is taking a small action to
enact the change they want to create.
As we have discussed, real change happens when you can change the behaviors of others. Whether you
are changing the minds of your team, stakeholders, or customers, it is important to track their current
behavior patterns and understand the behaviors you need them to adopt in order to make the change you
are seeking.
To determine vital behaviors, you might consult experts, scan the best and most-cited articles and
research, or perform a culture assessment by identifying norms and customs within the team. When
identifying the behaviors, evaluate which behaviors are constructive to the change you wish to promote
and notice examples of those who succeed where most others fail.
Use the six sources of influence
The authors of INFLUENCER: The New Science of Leading Change studied companies and individuals who
were successful or unsuccessful with implementing change, and they identified six sources or factors that
were correlated with successful change. When determining how to influence your target audience to
create change, you should consider using all of these sources to increase your chances of success. You may
even consider prioritizing these based on your knowledge of your audience. For example, some target
audiences may be most swayed by financial incentives, while others may be more incentivized by social
justice impacts.
Here are the six sources uncovered by the authors in their research, including a sample idea of how you
can use these examples in your work in tandem with our Product Owner involvement scenario (described
earlier):
1. Personal motivation: Are the individuals motivated internally to engage in the new behavior? Can
you help them “love what they hate”? Example: Ensure the Product Owner is timely, appreciative,
and effective while giving their feedback.
2. Personal ability: Are the individuals capable of performing the behavior? Do they have the ability,
knowledge, and skills to “do what they can't”? Example: Ensure that the developer knows how to
use the available demo tools and can easily send a quick video of the new feature in their email to
the Product Owner.
3. Social motivation: Are there social contacts or networks encouraging or discouraging this new
behavior? Example: Have the Development Team members remind each other in the Daily Scrum
to email the Product Owner before they finalize the work.
 4. Social ability: Does the team have resources within their social network to help them carry out the
new behaviors? Example: Give the Development Team a tool to track all of their demos to the
Product Owner during the Sprint.
5. Structural motivation: Are there rewards or incentives that they will receive if they perform the
new behaviors? Example: Provide a coffee gift card Sprint award that the Product Owner gets to
award after each Sprint.
6. Structural ability: Are there environmental factors at play that either deter or support the new
behavior? Can you make the incorrect behavior harder to do than the correct behavior? Example:
Add a rule to the content management system that pre-populates the name of the Product Owner
in the reviewer list.
Key takeaway
These three keys to influence make up the influencer change framework and will improve your chances of
success with a change. Clarify measurable results, find vital behaviors, and leverage six sources of
influence in tandem to lead an organization, team, or an individual to experience positive change.

Coaching versus managing in Agile

In the previous video, we learned about the importance of an Agile coach. In this reading, we will further
explore the work of a coach and how it differs from that of a manager.
Both managing and coaching play important roles in project management. The difference in each
approach is in communication. Management is about giving direction, while coaching is about teaching.
Some situations will call for coaching, and others will call for management. As a project manager, it is
important that you understand when each skill set is necessary for success.
Managing
So far, we have focused on the responsibilities of project managers. We know that project managers are
tasked with delivering a project objective and solving problems as they arise. Project managers keep team
members organized and on track. They streamline communication and give directions. This is very
indicative of a traditional management approach. At its core, managing requires overseeing the work of
others and can include:
• Onboarding and orienting new employees
• Conducting meetings
• Delegating tasks and assignments
• Monitoring progress and performance against those tasks
• Making high-level decisions
In Agile project management, however, teams are designed to be self-managing. A self-managing team
has the autonomy to choose how best to accomplish their work, rather than being directed by others from
the top down. Agile team members should also feel empowered and equipped to problem-solve on their
own.
Even so, there are some cases where the decisive action of a manager is required. Examples include if
there is an emergency that needs immediate action, if you are behind on a deadline, or if a client has very
specific needs and you are the most familiar with them. In a results-driven project with little room for
error, someone needs to step in and take the lead. That is where a managing approach comes in.
Coaching
Although managing seems inherent to project management, coaching is also an important part of the
project management role.
Coaching is a two-way communication style aimed at influencing and developing team members’ skills,
motivation, and judgment. Coaching empowers team members to arrive at solutions on their own by
teaching them critical thinking and decision-making skills. This is achieved through offering feedback and
providing opportunities for professional development. When challenges arise, coaches will offer guidance,
then get out of the way. Coaches don’t jump in during times of crisis in a way that a manager would.
Coaches ask questions to help team members arrive at conclusions on their own.
Coaches trust that their team members can make smart decisions, and trust can go a long way. When
team members feel trusted, workplace satisfaction increases, and the quality of work improves.

It is appropriate to use a coaching approach when a team member already has experience working on
similar projects and is working on growing new competencies or is trying a new approach for the first
time. Coaching is about building confidence and capabilities so that individuals can continuously grow and
improve. There are a few principles to keep in mind when coaching:
1. Motivate: Coaches motivate team members to take action. They point out the value in others’
work and instill within them a sense of pride in what they do.
2. Support: Coaches are an accessible resource for their team to come to when they experience
problems or if they have an idea they want their feedback on.
 3. Encourage and appreciate: When someone on their team is struggling with a heavy workload, a
coach will acknowledge and validate the weight of their efforts and assure them that they are
capable of handling the challenges ahead.
Coaching is appropriate in many circumstances, especially when you need to build up the confidence of an
individual or a team. The most effective leaders strike a healthy balance between managing and coaching
based on the needs of the situation, individual, and project they are leading. Examples of where coaching
would be helpful include when a team member is branching out into using a new technology or discipline
that will turbocharge their career opportunities, when an individual’s behavior is having unintended
consequences on the team dynamics that are not readily visible, or if a team is recovering from a setback.
Here’s a scenario where a project manager or Scrum Master should step in to coach a team: Imagine a
Scrum team has failed to launch a product that meets the customer needs Sprint after Sprint. The Product
Owner continues to communicate to the team that the features are not quite right, and they need to
rework the product in the next Sprint or release. The team feels deflated, and they are showing signs of
burnout because they keep working on the same three features. Here is a perfect opportunity to do some
coaching with the whole team. Consider bringing them together for a working session and cycle through
all three principles of coaching:
1. Motivation: Ask the team to brainstorm positive reasons why the customer is providing this
feedback and why it matters to create an excellent end product.
2. Support: Work with the team to capture ideas on how to streamline the customer feedback
process, such as a design Sprint with the customer in attendance.
3. Encourage and appreciate: Set up an event where the team celebrates the work they have
accomplished so far, and make the event fun and inclusive for all team members.
Key takeaway
Managing and coaching are distinct leadership approaches that each yield different results, and both
styles require effective communication. A managing style typically utilizes one-way communication to
assign tasks and give directives. Coaching relies on open communication in both directions to help develop
an employee’s or team’s skills, so they can become self-sufficient. Some team members and company
cultures will naturally favor one style over another, but both are necessary leadership skills. As an Agile
project manager or Scrum Master, you will use both styles. That said, in Agile and Scrum, a coaching style
is usually the best initial option since it will increase the capabilities of the team, leading to more agility
over time.
When deciding which approach to use, ask yourself:
1. What is the desired outcome?
2. What is the skill level of the team member who has encountered a problem?
3. What does the situation need now to reach the desired outcomes?
 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.