SCRUM & Agile

Tuesday, 1 November 2022

09:35
- The terms Agile and Scrum are often used interchangeably, but they're not the
same thing.

Agile is the label used to define a specific philosophy, mindset and value system as
a unique approach to project work. The goal of Agile is to observe the unknowns
around you.

Scrum has been the leading Agile framework for many years.

Scrum is the most commonly-used of all Agile frameworks.

Usually sprints are 2 weeks long
The Product Backlog is Managed by the PO
 • Scrum.org

• Search free use cases online

Scrum guide - 20 pages

Scrum basics Course on LinkedIn learning

Transcript

The scrum approach to project success

- Language changes around us all the time. It's like a living, breathing
thing. As we use and adapt words, new definitions are created to
match what they mean in current times. Similarly, the scrum we're
talking about is an adaptation of the word scrummage, taken from the
game rugby, but scrum from rugby, how does that work? Well, in
rugby, a scrummage, scrum for short, was the method used to restart
play in a match after a foul. Visually, it's eight players from each team
packed together with heads down, all trying to take possession of the
ball. So, not exactly the poster child for project management, but with
a little imagination, it makes sense. On a project team, the goal is to
get the project done. Historically, using traditional methods, this
meant planning and designing the whole project at the beginning and
sticking to that plan with no variation. In real life, project work is
completely unpredictable. It's impossible to know at the
beginning exactly how a project will unfold and how to best meet its
unique challenges. The Agile Project Management movement comes
out of a desire to adapt in real time to the changing circumstances that
teams face, and this is where the rugby team comes in. The founders
of the Agile movement recognize that, in rugby, the object is to move
the ball down the field, one possession at a time, so why couldn't
projects do the same thing? Why not change the focus from just
winning the whole game to winning each and every milestone and
deliverable? These innovators co-opted the word scrum to reflect this
new approach, an approach that breaks the deliverables and
milestones into smaller pieces and gets the whole team together to
focus on just that one goal until it's done. Like in rugby, if the small
individual scores happened on a regular cycle, winning the game or
delivering the project would take care of itself, so the sporting word
scrum has been transformed in the last several years to have a new
meaning. It means to run your projects more like a rugby
match, pursuing the small goals and deliverables that will get your
project done.

The agile revolution

- Being a traditional waterfall project manager made it really unlikely that
your project would be successfully completed, let alone according to the
plan you laid out at the beginning. It was more like being a
weatherman doing a forecast for a specific day next year. Except for
random luck, you'd be wrong. Waterfall, as a methodology, is not
inherently a bad thing. In some cases it makes good sense, like in building
construction, where a predefined set of steps, when executed in order, will
result in a building. You can absolutely plan and schedule that whole
project upfront. It happens every time a home or an office building is
built. The problem comes when applying the technique to highly empirical
work like software development. Empirical work is more like a science
experiment. You try something, check out the results, and if it didn't work,
you try something else. You certainly can't do that when building a
house, but with software or some other products, you do it every
day. That's the crux of why waterfall didn't work well for software
development. You literally cannot upfront plan the process of
discovery. The frustration of highly-skilled software developers working
on waterfall projects was the tipping point that led to the Agile
revolution. Tired of having a failure rate equivalent to a weatherman, these
individuals decided they had to come up with a better option. The result is
known as the Agile Manifesto. Grounding themselves in the mindset of lean
manufacturing, where you do just enough just in time to meet the
goal, they started figuring out how that applies to software
development. The result is the Agile Manifesto and its underlying
principles. Take a look at the Agile Manifesto. You can check it out at this
online address. As if these words weren't revolutionary enough, this group
of innovators supported this manifesto with 12 key principles. This
manifesto and the principles became the foundation for a new set of
project management and software development methodologies. There are
a couple of overriding themes that make Agile different. One of the key
changes is that we're asking our business partners to work with us
throughout the whole project, not just show up at the beginning to
describe what they want, then show up at the end and tell us how we
missed the mark. We need direct, ongoing interaction to deliver what they
really need. Another key is that we no longer want to measure
success using milestones and project phases. We want working software
to tell everyone how we're doing, and we want to hear feedback the whole
time. Perhaps the most revolutionary change is to allow teams to self-
organize. They'll do a much better job doing the design and tests from the
ground level than any upfront plan could do. Upfront planning is
theoretical. Evolving design is both practical and tactical. It'll get you to
your goals faster, with higher quality. Between the manifesto and its
principles, this group of developers was done being the high-tech software
versions of the weatherman. They were ready to succeed. There is a better
way to do software development, and it's Agile.
Scrum: The leading project methodology

- Scrum wants you to fail. In fact, it's known for the slogan, "Fail fast." No,
I'm not joking. I realize it sounds weird, but there's a very good reason for
this. Traditionally, project managers and developers would work for
months or years before seeing the results. Most of the time, around 80% in
fact, the software and projects failed. So, why, you might ask, are they
signing up for more failure? Well, really they're not. The trick is in focusing
on the second word, fast. Failure is okay, as long as you're learning from
it, but if you have to wait too long, you're not going to learn nearly as much
from it. Scrum takes the agile manifesto and its key principles and boils
them down to a very simple framework that encourages small scale focus
and rapid learning cycles. That's what fail fast really means, learn
fast. With that in mind, the basics of the framework are designed to
encourage that fast feedback loop. The scrum framework is not
prescriptive. We generally refer to it as guardrails, like the ones you see on
the highway. Those guardrails don't tell you exactly where to drive in the
lane, but they keep you within the boundaries that will result in a
successful road trip. Scrum is much the same. With the agile principles as
the guideposts and a loose framework of activities executed on a regular,
short schedule, your project will be get up for success. In a nutshell, here's
the scrum framework in its simplest form. To start, the product owner has
a prioritized backlog of work for the team to do. Every two weeks or so, the
team looks at the backlog and decides what they can accomplish in the next
two weeks. The team develops and tests their solution to the backlog items
until they're done and ready for use. At the end of the two weeks, the team
demonstrates their accomplishments to the product owner and
stakeholders. Finally, they reflect on how things went during the two
weeks and they decide what they can do to improve their work
practices. That's it. The short timeframe and the focus on a completed
product at the end forces the the team to fail fast or more appropriately,
learn fast.

Solve project problems with scrum

- Traditionally, waterfall project teams face three constraints: time, cost,

and scope. They are unable to change any of these things once their project
starts. The problem is during the course of a project the business
environment changes around you. This means by the time you're
done what you built is no longer valuable. This isn't anyone's
fault. Business needs are changing more rapidly than ever. Project
requirements are shifting just as quickly to keep up. So teams were
doomed to failure on every project, until the agile manifesto came
along. Then we shifted our focus away from constraining all three project
elements and decided to make one of them flexible, scope. That was
huge. You, the business person, can have this team, cost, for this long,
time, and you can build whatever you believe is most valuable. It's that
simple. All agile methodologies follow that first key paradigm shift. Lock
everything but scope, and you've got yourself a framework that will deliver
exactly what's needed as quickly as possible. Agile is a broad umbrella of
many methodologies that follow the same principles. Scrum is one of
them. Scrum took it a step further by creating a framework to help teams
stay focused and protect them from distractions. Essential to scrum are
two key roles: the product owner and scrum master. The agile manifesto
writers recognized that historically they didn't have access to the right
business experts as often as they needed to help guide their daily
decisions. Scrum solved this by creating the role of the product owner. This
business representative is committed 100% to the team. It's their full-time
job. They also realized there needs to be someone to help the team resolve
day-to-day issues and counterbalance the ongoing requirements
changes. So, the role of scrum master was developed to protect the team
enough to complete work without distractions. This dedicated role also
helps them improve their internal team processes. Beyond creating these
roles to help the teams, scrum says you need to deliver quickly so you
always know whether you're on track. In order to fail fast and learn
fast, you need a fast feedback loop. Scrum set the boundary for teams to
deliver value as anywhere from two to four weeks. You need to have
business-approved and customer-ready product completed that
often. Scrum also recognizes that if you're going to successfully deliver this
quickly the team needs to meet every day. This is what's known as a daily
standup meeting. Finally, the last key element of this framework is the
recognition that a healthy team needs time to reflect and think about what
they can do to improve. So scrum mandates a ceremony called the
retrospective where they can assess themselves and decide what to
improve. Really that's it for the framework. The focus of scrum is to
maximize the efficiency of the team. Since scope is the point of flexibility
for agile projects, scrum's focus is how to deliver the most possible
value within the constrained time and budget.

Essential roles for scrum teams

- Scrum is a lightweight framework that can be incredibly flexible, efficient,

and powerful. There are two key roles that exist on every scrum team: the
product owner and the scrum master. Let's start with the product owner,
or PO. The PO is the business representative on the team. They're not part
time team members. They show up every day, because they're
contributing to the final product every day. They review all the work the
team completes, and either accepts it or asks the team to make changes to
ensure the highest value is being delivered. Formerly, the business person
was represented through requirements documents that were rarely, if
ever, updated. On a scrum team, the PO is always ordering the work and
ensuring the team members clearly understand the details of the
requests. But that's only part of their job. They're also interacting on a daily
basis with the stakeholders. It's not enough for the PO to interact with the
team. They must also be in tune with all the changes that are occurring in
the business context. As a result, the PO is the keeper of the product
vision. He or she defines and manages the backlog of work to be done and
the prioritization of the those work items. Remember that scrum allows
the scope to be flexible. Since time and costs are locked, the PO is painfully
aware that the work must be continuously sorted to highest value
first. They'll also be pushing the team to complete as much work as
possible in each short delivery period. Now if you're wondering how on
earth a team can keep up with these demands, you're not alone. The
founders of scrum recognize the need to counterbalance the PO role, so
they created the role of the scrum master. The scrum master protects the
team and protects the process. The scrum master is the facilitator who
keeps the team within the guardrails of scrum. They balance the demands
of the PO against the needs of the team. This role is the first safety valve to
ensure teams are performing at a sustainable pace. We don't want them to
get burned out before they reach the finish line. That's a big statement if
you think about it. Scrum is a framework that doesn't value heroics by
teams or individual team members. It values sustainability and open
dialog on what can and cannot be reasonably accomplished. The scrum
master is the most visible spokesperson for the team. Scrum masters value
transparency. They'll devise charts and boards to share the team's
progress with anyone who's curious or interested in how they're
doing. They're also the first escalation point when something gets in the
way for the team. The scrum master will work to remove any blockers until
they're out of the way and the team can continue on. While the PO focuses
on what needs to be done, the scrum master focuses on how the team does
the work. And one more thing. The scrum master also holds the team
accountable for their commitments to the product owner. They show
trends in team performance over time to help the team improve their
processes and practices. As you can see, each role is absolutely critical to
getting the framework to function properly. If you're lacking one of these
roles, scrum will be far less effective than if you have them both.

Establish your scrum team

Scrum is all about daily collaboration and communication. Absolutely

anything you can do to make that easier for your team will pay big
dividends down the road. That's why, if it's possible, co-locate your team
members in the same room, aisle, or space to make that collaboration more
effective. In many companies, that's simply not possible due to building or
distance barriers. Some things you can try are video
conferencing, dedicated chat rooms, and conferencing phones in all your
locations. These can easily help your teams stay in touch. Now, let's talk a
bit about team composition. Your first priority is to ensure you have a
dedicated team. If your team members are multitasking between your
project and another one, they lose a lot of efficiency, and that slows down
your delivery. Dedicating your core team results in better focus, higher
efficiency, and faster delivery. The ideal team size is seven members, plus
or minus two. I know this sounds specific, but research indicates these
numbers maximize people's ability to create close relationships and
collaborate most effectively. Sure, you can have more people, but the
communication channels it takes to keep everyone in the loop gets much,
much harder for every additional person you add. In a perfect world, you'd
have a team made up of five to nine people who have absolutely every skill
you need to complete the work. Those are what we call T-shaped
resources. They have broad knowledge at a high level in several areas and
deep knowledge in just one area like a T. For example, I worked with a very
skilled Java developer, the vertical of the T, who also had database analyst
skills, the crossbar of the T. So she could work on more than one type of
deliverable. These types of resources can be hard to come by, so you'll
want to line up some consultancy resources that can be used when your
team needs specialized skills. Specialized skills that I've seen fairly
frequently are architects, database analysts, and security analysts. These
are people that you'll need once in a while to work with your team. But you
may not have enough work to keep them fully occupied. This is very
common. And with the right level upfront commitment and ongoing
communication, it can be highly successful. A small unit that works closely
together all the time will inevitably face internal conflicts. Some upfront
ground rules are needed to prevent trouble. We call these team norms. And
you need to help the team establish these before any work is even
started. These norms are commitments that the team members make to
each other about how they'll work together, how they'll resolve
disagreements, and how they'll reach design consensus. Just to give you an
idea, one of the most common Scrum team norms is to agree to disagree
but move forward with the decision the team's made. Another common
norm is something like when laptops can be used during meetings to make
sure everyone is focused on the conversation. You can even have norms on
how to hold each other accountable. You can get very creative with team
norms, but they must have the commitment of all team members for them
to be useful. They must also be fairly applied, and the team must trust each
other enough to hold each other accountable to honoring the norms. If you
take the time to work through these elements and help your team set the
stage, success can come more quickly for them. You'll be amazed at how
quickly your team can work effectively once you've set them up for
success.
 Set boundaries for success
Selecting transcript lines in this section will navigate to timestamp in
the video
- Your next step is to create boundaries that your team can use to complete this
work. These guidelines include the team's definition of done, prioritizing your
backlog, and establishing your sprint cadence. First, your team needs to define
done for their stories. I know each story has its own acceptance criteria, but this
definition is a little bit more general. This definition of done states the minimum
requirements for all stories. Since these apply to everything in your backlog, you
don't want to repeat these things in the AC of every story. Creating this
overarching definition of done helps save time, while allowing more precision in
the story's specific AC. Examples of done criteria for all stories are: For a story on
our team to be considered done, it has been tested in the prerelease
environment. Or, how about, for a story on our team to be considered done, it has
been code-reviewed and all errors fixed. Next, your product owner needs to
prioritize the backlog. This is known as backlog grooming. It simply means that
stories are continually sequenced in value order. The more valuable the outcome
of the story, the higher it is in the backlog. Remember, scrum allows flexibility in
scope, but is locked in duration, so the PO wants the most valuable stuff delivered
first. That way even if time runs out, a valuable product has still been
delivered. Finally, you need to establish your sprint duration or cadence. Scrum
says that your sprint can be anywhere from one to four weeks in length with a
preference toward the shorter time scale. Remember, the scrum best practices say
we should fail and learn fast. With that being the case, you should establish the
shortest feasible sprint length you can. When I work with teams, I generally
recommend they go with the two-week sprint cadence. This duration really helps
the team stay focused on what's happening within the sprint. A two-week sprint is
in the Goldilocks' zone. If your sprint is too short, teams tend to panic and quality
degrades. If your sprint is too long, the team will unconsciously relax their
pace. They feel like they have plenty of time. But this middle zone of two weeks is
just right. It creates a sense of urgency within the team without inciting
panic. Establishing these boundaries helps the team understand what done means
for every story, the value of specific stories, and the timeframe in which they'll be
delivering. They now have the execution framework they need to be successful.

Story points and estimation in scrum

- There are two kinds of estimation we all use every day. There's actual estimating
and relative estimating. Actual estimating is what you use when reading a map. It's
25 miles from point A to point B. This is very specific. Then there's relative
estimating, which is comparing things to each other to get a general idea of
something, like a giraffe is twice as tall as a zebra, or a cake is the same width as a
pie. In Agile and Scrum, we use both kinds of estimating. We use relative
estimation to get a rough size of our work by comparing user stories to each
other. This gives us an overall sense, or estimate, of how big something is. Stories
themselves are rough guides to how the user wants to interact with our
product. Because it's a rough statement of need, we can't be too specific on how
big it is. Also, since this is just a rough cut, we don't want stakeholders to think we
know precisely what it's going to take to get that done. Relative estimating helps
us maintain the mindset that it's just an estimate, not a commitment. At the same
time, when we commit to tasks, we'd better be pretty darn clear on what it takes
to do that task. So, when it's time to do the work, we need to be specific on how
long it will take, so that's when we switch over to actual estimation. Scrum teams
use planning poker to guide them through relatively estimating their stories. Story
points are the unit of measure we use to convey the relative sizes. Here's a great
detailed course on how to play planning poker with your Scrum team. Estimation
is meant to be lightweight and fast. It shouldn't take days, or even hours, to
determine how much effort you'll put into something. While it might take a little
bit of practice, once you get the hang of it, you'll fly through it.

Track your scrum progress

- If you're working on a critical project, it's pretty common for

stakeholders to ask your team members how things are going. This is
good, people are invested in the outcome of your project. Scrum addresses
these challenges, by posting information radiators. An information radiator
is anything that you post on walls or team sites, that help everyone
understand what you're doing and how it's going. These can take as many
unique forms as needed for your environment and project. I've seen teams
visibly post the vision for their project, the team norms, their teams
definition of done. Their roadmaps and the release plan. At a
minimum, teams post their task board and their burndown chart. So, let's
talk about those in a bit more detail. The task board can take any form you'd
like, but it has a few key components. It shows the stories committed to you
in the Sprint. The tasks and their current status, and what tasks have been
completed. This is a simple example of what a task board looks like. It clearly
shows the committed stories and the related tasks. It goes further, by
showing what tasks have and have not been started. Finally, it shows which
ones are done. This simple tool, very easily tells everyone what the team is
working on. This board becomes the heart of your Sprint execution. The
team will gather around it to track what's happening in their Sprint and help
each other, if it looks like someone is stuck. Another primary tool for sharing
information on your progress, is The Sprint Burndown chart. This is used by
the team to measure how well they're executing the Sprint. Where the task
board tells you about task completion, it doesn't tell you how that
compares to where you are in the Sprint, a burndown does that. Here's an
example of a sprint burndown. As you can see, the burndown tells you
exactly where you are in the Sprint by day and how much work you
committed to do in the whole Sprint, or hours. Ideally, you'll burndown in a
linear fashion. The actuals line tells you exactly how you're doing in
comparison to the ideal. This is a very powerful tool, showing the team and
all the stakeholders how the team is progressing. Easy to create, easy to use
and understand, these are the hallmarks of great information
radiators. These will serve your team well and your stakeholders will
appreciate having a clear status.
The daily scrum or standup meeting

- The scrum master, as the scrum process owner, will establish your daily
scrum. This is also commonly referred to as the daily standup meeting or
standup for short. In order for scrum to work, it relies on the three Cs:
collaboration, communication, and cadence. The standup includes all
three. It's the foundational element of collaboration. It includes everyone on
the team: the developers, the testers, the PO, and scrum master. It occurs at
the same time every day, so your scrum master will select a time for the
standup that works for everyone. For teams that are co-located, or within a
few time zones, this is pretty straightforward. For international teams, this
can be a bit more challenging. But with today's video capabilities, this is
surmountable as well. I've seen teams where members in one country film
their standup meeting and send it over for team members in other countries
to watch as part of their standup. The bottom line is that your daily
standup is one of the non-negotiables of the scrum framework. It's usually
held in front of the team's task board whether it's electronic or physical. This
is the time when tasks are moved across the board. At the same time, your
standup is not a progress report. No one should be delivering a blow-by-
blow of their activities. Just the overview. Stakeholders are also encouraged
to attend, but ask them to hold their questions and comments until the end
of the scrum. Daily scrum is short. It's limited to 15 minutes. It can be
shorter, but it cannot be longer. The whole team stands to keep it fast, thus
the shorthand name, standup. Really if everyone is sitting down, it starts to
feel like a meeting and it can drag on like meetings tend to. The scrum master
also limits updates to three questions per person. What did you do
yesterday? What are you going to do today? And is anything blocking your
progress? As individuals go through these questions, the whole team
understands their progress as a unit and sees how their work fits into the
whole. At the same time, if a team member didn't complete something the
day before, or for several consecutive days, this is the team's opportunity to
hold them accountable. This isn't done in a mean spirited way. It's simply
hard to face your peers and admit you've missed your goal. It's a daily
opportunity to ask for help. One of the most powerful aspects of scrum is the
immediacy in which issues are resolved. If someone on the team says they
have something blocking them, the whole team has the ability to step in and
help. If it can't be resolved within a day by the team, the scrum master steps
in. If the scrum master can't fix it in a day, it goes to the PO to help solve the
next day, and so on. These escalations then continue until the blocker is
removed and progress can be made again. The daily scrum is the expected
cadence for communication and collaboration. Scrum teams collaborate and
communicate all day long. The daily scrum is just the formal version so
everyone gets to see and hear the team's collective progress.

Backlog refinement in scrum

- In Scrum, the Product Owner is accountable to the team and the

stakeholders. The stakeholders want to ensure they get what they need from
your project. A key aspect to keeping the right priorities throughout the
project is the ongoing refinement of the Product Backlog. This means that
the PO is out there meeting with stakeholders to understand what's
needed. They're constantly moving the work around as the business needs
and requirements shift. Throughout the project, your backlog is constantly
changing as new features and stories are being discovered and added. Other
stories are being changed and maybe even removed. As new stories are
discovered, the PO works out the details and AC for each one. But at least
once per sprint, the whole team comes together to see what new items have
come up. This is usually a 30 to 60-minute backlog grooming session. It
usually happens around the midpoint of the sprint. The PO reads the new
stories to the team, and the team asks about any details that are missing. The
PO then goes to find answers to the team's questions. Once done, the PO
decides what the priority of the new stories are and adds them to the
backlog where they think the stories fit. Now this might sound a little
scary, but there's a safety net in place to protect the team and the sprint
commitment. The PO can only add stories to future sprints. The sprint that's
in progress is off limits. So yes, your backlog will change throughout the life
of the project. But know your sprint commitment can't be changed once the
sprint is underway. This helps the team keep their commitments, but also
allows the Scrum team to adapt to the changing business needs throughout
the life of the project. The other advantage of ongoing backlog grooming
sessions is that the team gets to ask the PO for clarification well ahead of the
sprint planning and commitment meeting. If the details can't be ready in
time for the sprint planning meeting, the story can't be added to the
sprint. This ensures there are no surprises once a sprint is underway. These
interactions also help the PO know where there are gaps in the
requirements. It empowers the PO to fill those gaps in a way that doesn't
delay the team. The team gets to keep working on the current sprint while
the investigation happens. Backlog grooming then is one more way in
which business needs can be continuously identified and prepared for
delivery within a sprint. It's a great tool to foster understanding and
collaboration across the whole team.

Get stories done in scrum

- In scrum, the team takes their sprint commitment very seriously. They're
striving each day to collaborate and get their stories to done. Since that's the
goal, the team is developing and testing the entire time to ensure all the story
AC are met. The AC approval though has to come from the product
owner. Since the product owner is the business representative on the
team, their acceptance or rejection is the final word. That means that
throughout the sprint, team members are checking their work with the
PO. Each story that's accepted can then move across the task board to the
Done column. Some teams hold a brief, more formal session known as the
sprint review. During this ceremony, the team and PO meet to review the
sprint as a whole. This is a check point where everyone looks at each story
from the sprint and sees which ones were done. Anything that isn't accepted
as complete is reviewed, prioritized, and moved out to another sprint. In
some cases, the team has discovered new information about a story and it
needs to be split into smaller ones. Once those are split, they're also
prioritized by the PO and then moved to the appropriate sprint. Finally, the
team collectively understands and agrees on what was done and can be
demonstrated to the larger stakeholder group. This meeting is meant to be
short and simple. What did we do? What do we still need to do in a future
sprint, and what's ready to show off? This session is another step in scrum
collaboration. The team acknowledges their progress and keeps their eye on
what's coming. This collaboration helps the team maintain awareness of the
whole project. It keeps the team focused on the big picture while delivering
a usable product in every sprint.

Demo the team's work

- In scrum, we strive to deliver a working product at the end of every

sprint. But what's the point if no one knows about it? Scrum's answer to this
is the demo. As you know, the PO is accountable for accepting or rejecting
what's been delivered. Whatever they accept is ready to be demonstrated, or
demoed to a larger audience. Remember, the PO is accountable to the other
stakeholders as their representative to ensure they get what they want. The
demo is how the PO and team make sure the stakeholders are happy with
what we're delivering. The demo is a powerful ceremony for scrum
teams. The demo builds trust between the team and the stakeholders, which
comes in a few ways in this context. First and foremost, this is a forum for
direct conversation with the stakeholders. This group has a vested interest
in the success of the team and the product. It's a great opportunity for the
team to receive direct feedback. The stakeholders get to see for
themselves the work being done on their behalf. They provide feedback to
the team. Both praise for what's been done, and suggestions for changes,
also known as new stories. The PO will capture these and after the demo, set
about adding details and vetting the new stories for the backlog. Sometimes
the stakeholders will see something that's demoed and decide they don't
want it after all. That's completely okay. Better to hear it now and catch it
right away. The team can then pivot to what the stakeholders do
want. Another advantage of the demo is to let the stakeholders know who is
working on their project. They get to see for themselves the skills and
dedication each team member brings to every sprint. This is an opportunity
to build relationships between the team and stakeholders. This visibility
gives the stakeholders a broader, more balance perspective on what it takes
to create their product. Additionally, the stakeholders will see the team's
willingness to receive feedback and adapt to their changing needs. Finally,
the demo shows the overall progress toward the final goal. Your PO will keep
your product roadmap and release plan up-to-date after every sprint. This is
where you show them to your stakeholders. Your team is bringing the
stakeholders along on the journey with them. The stakeholders can also
provide feedback on the timing and contents of each planned release. Again,
another trust and relationship building exercise. You might be wondering if
you have to demo at the end of every sprint. The answer is no, you don't. But
you need to demo as often as possible. It only helps you to build trust with
your stakeholders and prove the progress being made for them. Your
product will be more robust and widely accepted when you receive regular
feedback to help perfect it. One of the best things about scrum is its
transparency in making everything visible to everyone. Be sure you demo
regularly to keep your product and stakeholders in close alignment.

Assess the team

- For a scrum team, 100% of every sprint is focused on the needs of the
stakeholders and the end users. But the principles behind agile say that
teams need to reflect regularly on how to be more effective and adjust their
behaviors accordingly. In scrum, this principle has taken shape as the team
retrospective, or retro for short. This is the one time every sprint when the
focus is not on the product. It's on the team itself. Since the focus is on the
team and team processes, the scrum master facilitates this ceremony. In
order to have a successful retro you must have a safe environment. As a
result, this is a closed-door session. The team must know that only dedicated
team members will be present and that the team norms will be
observed. This sense of safety is essential to ensuring the open
dialogue that's needed to really assess honestly the way the team is working
together. Usually the agenda for the retro is simple. It consists of three
questions. What worked well, what did not work well, and what will we
improve? While everything on this list is important, be sure to start with the
team successes first. I know this sounds backwards. We're here to get
better. Why focus on what we already do well? But in order to help the
team stay away from responding defensively, you need to appreciate
them. Fill their emotional bank accounts before you start sharing the
improvement areas. When you focus on question one, pay attention to
everything the team did well that's within their control. This includes
examples of great collaboration both inside and outside the team. Recognize
things the team has done to help each other out. Be sure to focus on the team
itself, not the stories they've completed. By focusing on success, the team
creates a positive behavior loop. They'll want to become better so they have
more to celebrate the next time. When moving to question two, what didn't
go well, be sure to focus on things that you can change, not on outside groups
or tools that are beyond your control. For example, perhaps your team needs
to use a specific testing tool and the tool is slow. Your improvement area
wouldn't be to fix the tool. It would be to find a better way to use the tool
more effectively. After you have a good list of improvement areas you can
move to question three, what do we want to focus on? All of the items
identified for improvement move to an improvement backlog. It's not
feasible to work on everything at once, so the team needs to decide which
one or two items to focus on in the next sprint. During the next sprint, the
scrum master will hold the team accountable to the improvement
commitments as well as their story commitments. In this way, the scrum
master helps protect the team's commitments to themselves too. All of the
other tools scrum teams use are about the product. The retro is powerful
because it's about the team itself. Remember, scrum is a framework that can
only be successful when the team is healthy and focusing on improving
themselves as well as their product.