Scrum Master:

21 Sprint Problems, Impediments

and Solutions
Table of Contents

Introduction
Tip 1: Make a Point of Not Planning Up Front
Tip 2: Don ’ t Worry About Advanced Tools
Tip 3: Use the Daily Scrum Properly
Tip 4: Do Not Give Out Tasks
Tip 5: Don ’ t Dwell on a Failed Sprint
Tip 6: Keep the Scrum Master Separate
Tip 7: Keep Your Product Owner Involved
Tip 8: Don ’ t Use Stretch Goals
Tip 9: Make it Clear that Individual Sacrifice is Not Required
Tip 10: Avoid Letting the Team Organize the Product Backlog
Tip 11: Know When an Interruption is Serious Enough to Warrant
Canceling a Sprint
Tip 12: Do What You Can to Avoid Lagging Sprint Times
Tip 13: Properly Prepare for All Demos
Tip 14: Work to Create Potentially Shippable Products
Tip 15: Do What You Can to Keep the Team Intact
Tip 16: Avoid Imposed Limitations
Tip 17: Know What Done Means in Context
Tip 18: Find the Right User Stories
Tip 19: Discuss Features with Product Owner before the Sprint
Review
Tip 20: Use Roundtable Discussions in Retrospectives
Tip 21: Deal with Leftover Work the Right Way
Introduction
Thank you and congratulations on taking this class, “Scrum Master:
21 Sprint Problems, Impediments and Solutions”.
In this class, you will be given a multitude of proven solutions that
you can use to effectively solve common, problems, blockers or
impediments and improve the productivity of your agile scrum teams.
Delivering complex projects is never a straight line. Therefore, I
know you will get value from this class as it gives you a brief
introduction to the concept of the sprint. I then talk you one by one
through each common (and uncommon) project problem and
suggested solutions. Along the way, as usual, I will give you plenty
of examples and enlightening insight for how to remove obstacles
and increase productivity within an agile scrum team. In this class,
you will learn:
✓ A brief recap of agile and scrum principles
✓ What is a sprint and why it is often challenging to complete
projects on time, even using sprints
✓ Key principles to use when solving impediments
✓ Concise tips for solving common and uncommon
impediments within scrum

So let ’ s get started and let me teach you how to solve impediments
in your sprints using agile scrum.
© Copyright 2016 by Pashun Publishing Press - a division of
Pashun Consulting Ltd. - All rights reserved.
This document is geared towards providing exact and reliable
information in regards to the topic and issue covered. The
publication is sold with the idea that the publisher is not required to
render accounting, officially permitted, or otherwise, qualified
services. If advice is necessary, legal or professional, a practiced
individual in the profession should be ordered.
- From a Declaration of Principles which was accepted and approved
equally by a Committee of the American Bar Association and a
Committee of Publishers and Associations.
In no way is it legal to reproduce, duplicate, or transmit any part of
this document in either electronic means or in printed format.
Recording of this publication is strictly prohibited and any storage of
this document is not allowed unless with written permission from the
publisher. All rights reserved.
The information provided herein is stated to be truthful and
consistent, in that any liability, in terms of inattention or otherwise, by
any usage or abuse of any policies, processes, or directions
contained within is the solitary and utter responsibility of the recipient
reader. Under no circumstances will any legal responsibility or blame
be held against the publisher for any reparation, damages, or
monetary loss due to the information herein, either directly or
indirectly.
Respective authors own all copyrights not held by the publisher.
The information herein is offered for informational purposes solely,
and is universal as so. The presentation of the information is without
contract or any type of guarantee assurance.
The trademarks that are used are without any consent, and the
publication of the trademark is without permission or backing by the
trademark owner. All trademarks and brands within this class are for
clarifying purposes only and are the owned by the owners
themselves, not affiliated with this document.
Before we can discuss the specific details about how to make the
most use of a scrum, let’s first understand what agile scrum is all
about.
What is Agile Scrum?
In a nutshell, agile is an umbrella term for a set of frameworks and
methods. These use iterative time boxed approaches and focus on
building products incrementally from the beginning of a project rather
than delivering it all at once at the end. Agile basically encourages
frequent inspection and adaptation plus teamwork, accountability
and self-organization. Moreover, the engineering behind agile
projects allow speedy delivery of first-class products and their
business approach aligns development with company goals and
customer needs. Agile often works by breaking down projects into
tiny user functionality bits called user stories, which are prioritized
and then continuously delivered in short cycles (mostly 2 weeks)
called iterations.
Scrum is an agile framework that traces back to early 90s, which
provides a framework for managing complex product and software
development with iterative and incremental processes. Scrum is a
very popular framework for implementing agile project management.
Although some people think that agile and scrum is the same thing,
this is wrong. While there are many frameworks for implementing
agile, scrum is the most outstanding owing to its specific concepts
and practices categorized into roles, time boxes and artifacts. And
although scrum is an agile technique that can be used for any
project, it’s mainly used for developing different software. It’s mostly
suitable for projects with requirements that change and develop very
fast.
Agile methods (including Scrum) implement the agile manifesto of:
• Individuals and interactions above tools and
processes
 • Working software over comprehensive
documentation
• Customer collaboration above contract
negotiation
• Responding to change over following a plan
Scrum Theory
Scrum is based on empiricism or empirical process control theory.
The simple idea behind this theory consists of three principles:
transparency, inspection and adaptation. Transparency (honesty)
among the scrum team members is emphasized in that the product
functionality is not ‘done’ until the team says so.
Transparency creates trust among the team members and enables
them to consistently check up the progress (inspection) and make
improvements based on what they see (adaptation). These
improvements include practices, communication, sticking to values,
or otherwise. Consistently inspecting and adapting is quite powerful
stuff. In so doing, they are improving over and over again, during and
after the release of a product a feature that’s not possible with other
models of development.
Generally, the components of scrum framework are:
1. Three roles: Product owner, scrum master and scrum
development team
2. Sprints: A project iteration of less than a calendar month
3. Scrum events/ceremonies: Sprint planning meeting (what and how
meetings), daily scrum meetings, sprint review meeting and sprint
retrospective meetings.
4. Scrum artifacts
Scrum has three artifacts:
a) Product Backlog: a prioritized backlog with end user requirements;
the product owner is responsible for this (refer to the next section)
b) Sprint backlog; Elected items from the product backlog. It’s like a
mini-plan for achieving the sprint goal and delivering the product
increment. Forecast the functionalities in the next increment and
what needs to be done to deliver that functionality. The development
team are responsible for this.
c) Product increments: At the end of each sprint, the new product
increment should be in a functional state and meets the scrum
team’s definition of “Done”. If all works well and the team’s
estimation stays on track, the increment has all sprint backlogs’
items, meeting the team’s definition of done.

To help you to understand this better, let’s talk more about these
components of the scrum framework:
1. The three roles
The entire scrum team is made up of three roles.
The product owner (PO)
Before carrying out any scrum project implementation activity, you
need to find a relevant person who is willing to be a product owner.
The product owner is a person who guides the team towards
creating the right product and is solely responsible for managing the
product backlog by:
✓ Ordering the product backlog items inline with the goal and
vision
✓ Ensuring these items are clearly defined and explained to
all team members and that the backlog is visible and
transparent enough to the team
✓ Giving the team their next agenda and optimizing the value
of the team’s work.
However, although all these can be done by the development team,
the PO remains accountable. If there are changes to the backlog
item’s priority, the PO must be involved. For the project to succeed,
the PO’s decisions need to be respected.
Scrum master
The Scrum master is responsible for explaining and enacting scrum
and makes sure those outside the team understand whether their
interactions with the scrum team are helpful or not. The Scrum
master serves the product owner, the team and the organization in
the following ways:
✓ Helps PO find effective product backlog management
techniques.
✓ Helps the scrum team understand why the product backlog
must be clear and concise.
✓ Helps the development team develop high quality products
✓ Facilitates scrum events when needed
✓ Acts as a coach; teaches both the team members and
organization how scrum operates
✓ Protects the team from external interruptions and gets rid
of any impediments to ensure peak performance
✓ Plans the implementation process in accordance with the
scrum theory
Scrum development Team
This team consists of professionals that work towards delivering an
almost releasable increment of what’s referred to as a “done
product” after the end of each sprint. They have every skill
necessary to create what’s referred to as “a product increment”.
✓ They’re solely responsible for creating any increment.
✓ They decide on the number of priority items or user stories
to complete during a sprint.
As a member of this team, you’re referred to as a developer
regardless of what you actually do (no titles). In addition, there are
no sub-teams when it comes to addressing various issues like
business analysis or testing; everything is done as a team. The size
of the team must be small enough to stay agile and large enough to
finish all the chosen tasks in a given sprint. Select a development
team of three to nine people to avoid issues such as poor delivery of
potentially releasable product increments (for extra small teams) and
poor coordination or management (for extra large group). Unless the
PO and scrum master are also executing sprint backlog’s work,
they’re not include in this count.
Key Characteristics of the Scrum Team
-Self organization is important in all agile scrum projects. The team is
self-organized in that there is no overall team leader or project
manager to impose stuff on the team. Decision making includes all
team members (all inclusive). In agile scrum, the PO and scrum
master support the whole scrum team but the team decides on what
and how much to do in a given sprint. The scrum team is also cross
functional, which means everyone in the team is capable of and
involved in taking any feature from idea to implementation without
outside help.
-Continuous improvements; inspect & adapt, is another central
aspect in scrum in that the scrum team must regularly inspect and
assess their products and processes for adaptation and
improvement purposes. Doing this optimizes results, increases
predictability and therefore minimizing the overall risk. Scrum works
on the maxim that requirements could change quickly or cannot be
fully known at the start of the project.
-Communication is another cornerstone of scrum framework. To
identify and prioritize functionality, the PO works closely with the
scrum team. This functionality is presented in form of user stories
and then stored in a product backlog. (I’ll tell you more about user
stories and product backlog later on).
2. The Scrum Events
Scrum projects progress through a series of sprints which form the
backbone of these projects. A sprint is a project iteration that takes a
period of time less than a calendar month, within which the
development team works on their tasks until they develop a working
increment of the product.
Sprint planning meeting: Time Box: 8 hours for a one month sprint
Planning Meetings are held at the beginning of each sprint which
lasts a maximum of 8 hours (for 1 month sprints). It is attended by
product owner, scrum master and scrum team.
During the sprint planning meeting, the PO submits and describes
the prioritized product backlog and explains to the team about the
sprint goal and product backlog’s top items. The team agrees on
which prioritized items to complete during the upcoming sprint and
then shifts these items from the product backlog to the sprint
backlog-a list of necessary tasks that they’ll do during the sprint to
attain the sprint goal. In doing so, they break each product backlog
item into specific tasks they can effectively do during the sprint.
Conceptually, the team selects the items to complete starting from
the topmost, and then draws a line on the prioritized backlog after
the lowest high-priority item they’ve selected.

After this meeting, the sprint kicks off. During the sprint, the
development team takes a few ideas, create them and tests their
functionality. In the end, these features become created, tested and
eventually integrated into the developing product or system.
Daily scrum meeting; Time Box: 15 minutes
Every day, during the sprint, the scrum master, scrum team and or
product owner (optional) must attend a daily scrum meeting of less
than 15 minutes.
During these day to day scrum meetings, the team members talk
about what they worked on the previous day, what they’ll work on
that day and identify any setbacks to progress. This daily scrums
synchronize the scrum team’s work plus their project knowledge,
communication and decision making is enhanced.
Sprint review: Time Box: 4 hours for a 1 month sprint
At the end of each sprint, the scrum team carries out a sprint review
which lasts for four hours for a 1 month sprint. During sprint review,
the team demonstrates the new functionality to the PO scrum
master, customers and other stakeholders/sponsors interested in
providing feedback that may perhaps influence the following sprint.
The relevant stakeholders express their impressions and clarify
whether their user stories/requirements are well implemented. The
PO ascertains whether the product is really “Done”. This feedback
loop could lead to changes to recently released functionality or just
lead to revising or adding items to the product backlog.
Sprint retrospective meeting; Time Box: 3 hours for a 1 month sprint
The Sprint retrospective meeting is another event in scrum attended
by the entire scrum team at the end of each sprint. The entire team
comes together to reflect on the sprint that has just ended as well as
spot any improvement measures needed. They generally talk about
how to make their work more effective and efficient in the future.
While the sprint review is on the product, sprint retrospective
meetings focus on the process.
3. The Scrum Skeleton
A very easy way I’ll use to further explain the agile scrum process to
you is using a scrum skeleton.
Here is diagram showing a scrum skeleton

On the left side of the skeleton, you can see the product backlog and
a sprint backlog is adopted by the team, split into tasks, and worked
on during a sprint. The team carry out requirements gathering and
specification update before the sprint, followed by design,
implementation and testing.
The smaller circle you see above the large sprint circle represents
the fact the team meets every day (daily scrum meeting) to inspect
on progress and adapt their plan for that day. At the end of a sprint,
they deliver a potentially shippable increment of the product. The
business can then review the increment (sprint review) and if
preferred, they can release the new feature(s).
The team engages in a transparent discussion about their progress
during a sprint retrospective (inspect) thus improve (adapt) on stuff
that needs to be improved or maintain the stuff that is going well.
The cycle starts all over again and repeats until there is nothing
more for product owner to add to the product.
The scrum skeleton shows that scrum is a simple and powerful mini
factory, manufacturing shippable features in every sprint.
These agile scrum concepts and practices are applicable to any
team or individual who needs to deliver a great project/product.
Tip 1: Don’t Overplan Before Starting a Sprint
Many teams, especially when they are first getting start with Scrum,
still feel the need to do some type of discussion or planning before
they get started. This can, in turn, lead to what is known as analysis
paralysis. This occurs when the planning stage of any given project
will often grind progress on that goal to a halt as buy-in is obtained
from several different sources over the course of days, or even
weeks. Don’t forget, Scrum was designed to be an adaptable
framework for inspection, which means that by its very nature it is
antithetical to have several team members sitting around waiting for
a single to finishing preparing so they can get to work.
It is important to remember that in order for Scrum to be used
correctly, users need to value the act of creation and, as such, the
potential for failure inherent therein, not just the documentation of the
process. It also values the individual bonds that ensures individuals
work well together as opposed to blindly following a set group of
rules. This means that while there is no harm in a certain individual
from doing some early legwork on a project before bringing in the
whole team, the point that this starts to be a detriment is where
waiting for this one person starts keeping a larger number of
individuals from generating any real type of value for a prolonged
period of time.
While finding the right mixture of pre-production and production can
be difficult at first as you don’t have a clear idea of what exactly it is
you are looking for from you team, it will get easier to pick out with
practice.
Suggested Solution(s)
Rather than taking the time to have multiple planning meetings
before you go into the sprint planning meeting, teams can instead
simply get started and use the opportunities to provide feedback that
are presented in the time allotted for Sprint Review and Sprint
Retrospective to adjust workflow as needed. This can be extended to
the creation of the Product Backlog.
While you and your team may initially find that starting a sprint
without first refining everything in the product backlog can be difficult,
it is nevertheless, completely possible assuming of course that the
team already has at least a good idea of what is required in the
product vision enough refinement for the first sprint. Using this
information, your team should be able to, at the very least, come up
with a realistic idea of what their first Sprint should consist of prior to
getting started. Remember, the key words here are getting started.
The goal during this initial sprint should be able to come up with
something that can be demoed, and possible evened shipped in line
with the product vision and release goal.
While sometimes this will result in product increments that are need
to be improved or changed, the point isn’t to get everything right
straight out of the gate but to instead get everyone working through
the Inspect and Adapt cycle as quickly as they can, as long as it is in
line with the current product vision. This, in turn will require actual
stakeholders to attend the demo at the end of the initial Sprint in
order for you to determine how successful it actually is.
In Summary
* A Sprint can be started without a fully refined Product Backlog as
long as you have a product vision and enough refined stories for
the first sprint of work.
* Use the Sprint Review phase and retrospective to reflect on the
first sprint. This should ensure your team can get started on a new
project with minimal planning as quickly as possible.
Tip 2: Don’t Worry About Advanced Tools
It is common for new teams to put off starting the Sprint process
while they look through the myriad of different types of tools that are
available to help them make using Scrum as simple and easy as
possible. While there is nothing wrong with looking into finding a
good Scrum tool, it is important to do so only when you have a clear
idea of just what facets of the Scrum framework that you need
electronic help with.
The impetus to do so is obvious, especially in teams that already
work for technology companies. After all, why wouldn’t you use
technology to solve this problem as well as all of your others? In
reality, however, Scrum electronic tools can often be more effort to
set up than their more analog equivalents. This occurs for several
different reasons that can generally be broken into three different
categories, first, they may require a technical knowledge to set up.
Second, they actually may need a third party or support team to set
them up.
Looking into fancy tools this early in the process is akin to putting the
cart before the horse, it is more important to get started at all then to
get started in the perfect way with the perfect tools. Being extremely
particular about a specific tool set is an easy way to put off starting to
use Scrum while still feeling productive about doing so. Don’t let
yourself fall into this trap, get started with what you have available
and work on improving from there.
Suggested Solution(s)
When first getting started using the Scrum system, you should find
that all of your tracking needs are easily met with a simple pen and
paper cards (5 by 3 index cards). This will let you get started quickly
and easily and get into your first Sprint without first ensuring that
everything is as absolutely perfect as possible. Additionally, most of
the time you will find that the simplest and most effective way of
reliably improving communication within your team is by simply
ensuring that everyone who is working on a given project is
physically located near one another.
Additionally, you are going to want to ensure that the space has
plenty of whiteboards or other writing spaces and that everyone is
seated together as opposed to be segregated off into their own little
spaces. Finally, you are going to want to ensure that the group has
it’s own area but it still near enough to the rest of the organization so
they feel as though they have a bit of privacy but can still
communicate easily.
In Summary
* For the avoidance of doubt, tools are often helpful. You may
introduce a tool early on if it is easy to set up without slowing the
team down. If not, delay the set-up or find a third party to set it up
(maybe the scrum master).
* The easiest way to start Sprint quickly isn’t always to start by
improving the tools you are using, it is to improve communication
amongst your team.
* Don’t worry about electronic solutions, analog solutions are likely
going to work just as well for quite some time.
Tip 3: Use the Daily Scrum Properly
When it comes to causing unexpected delays, there are few things
that can slow a Sprint down than a Daily Scrum that takes longer
than it should . This can be because certain members of the team
want to use the time to instead look for solutions to problems that
don’t affect the team as a whole. When performing the Daily Scrum,
it is important that you allow it no more than 15 minutes of your day,
at the very longest. In fact, as long as you have a properly
functioning physical task board, you will find that the Daily Scrum
can be finished in just a few minutes as each team member then
only has to point to the various different tasks that they are working
on (without reading it out, since everyone can see it).
Suggested Solution(s)
If you find yourself in a situation where a pair of team members do
bring up a problem-solving issue during the Daily Scrum, it is going
to be your job, or the job of the Scrum Master if it isn’t you, to keep
the meeting on track so that everyone else can get back to work as
quickly as possible. Then, once the meeting is over, the Scrum
Master can meet with the individuals who are experiencing the issue
in order to help them resolve it as quickly and easily as possible.
It is perfectly normal for some team members to require additional
detailed discussions some days, depending on the nature of their
specific work, but this isn’t what the Daily Scrum is for, in fact, there
are three different questions you can ask your team to ask
themselves in order to ensure everyone as a group is using the Daily
Scrum as effectively as possible. The first question should always
be, “what have I been doing between the last Daily Scrum and this
one to help meet the sprint goal?” The second question should be,
“what will I do before tomorrow’s Daily Scrum to help meet the sprint
goal?” Finally, they are going to want to ask, “what is currently
preventing me from getting work done in the near future to meet the
sprint goal”.
Each team member should answer each question in a quick and
orderly fashion. It is important that every team member always
participate fully as the scrum will likely lose focus if the other team
members need to work with a hesitant team member to ensure they
are sharing properly. If this is the first Sprint that your team has been
through, you are going to want to have the Scrum Master pay careful
attention to the timebox, the Daily Scrum has been given as it will
likely take a while for the whole team to get completely on board with
the overall short and sweet flow of the activity.
In Summary
* Keep Daily Scrum’s short and to the point, the shorter and more
focused they are the better.
* If there are problems that need to be solved, solve them after the
Daily Scrum to allow everyone else to get back to work as quickly
as possible.
* If your team has never been through a Sprint before, be prepared
for the Daily Scrum to take some getting used to.
Tip 4: Do Not Assign Tasks To Others
Despite the fact that in order for a Sprint to proceed smoothly,
individual team members require autonomy, many teams find they
have an especially difficult time getting away from the habit of having
certain individuals assigning tasks to other members of the group.
Assigning tasks can be extremely overt, or it can be more subtle,
which is another reason it can be so difficult for teams to get out of
the habit of operating this way. If, for example, both a discipline lead
(such as QA tester) and various team members who report to that
person (such as junior QA tester) are used to proceeding based on
what the lead decides, then even if the lead only vaguely mentions
various tasks that need doing, those team members could, quite
naturally, misconstrue those statements as an instruction for them to
assign tasks.
Everyone should be ready and willing to accept tasks at all times
with the exception of the Scrum Master and the Product Owner who
each have differing roles that limit what exactly they are expected to
volunteer for. However, the Development Team has no such
limitations which means they should know they have the absolute
freedom to approach the work that is required of them in the most
effective overall way possible. If a team member isn’t pulling their
weight, the Daily Scrum should make this relatively obvious without
singling out the lagging individual.
Suggested Solution(s)
Remember, when it comes to a Sprint then it is always better to wait
for a specific team member to step up to the task at hand rather than
getting ahead of yourself and assigning tasks. Rather, if there is
going to be a discussion of what needs to be done and when, then it
is best to have that conversation with the team as a whole with every
individual contributing based on what they feel is required of the
team at this point. Not only will this make it more likely that individual
team members will exhibit their own authority when taking tasks, it
will get the entire team more used to working in a thoroughly
collaborative environment.
Remember, your goal in this scenario is to get the entire team to stop
thinking about things in terms of a single authority figure at the top or
a handful of authority figures who all direction comes from as this is
only going to lead to bottlenecks when it comes time for actual work
to get done. If you ever want your team to start actively volunteering
for various available tasks using Scrum, then you need to give them
the opportunity to do so by ensuring that tasks never appear as
though they are assigned under any circumstances.
In Summary
* Assigning tasks can either be an overt action, a subtle
suggestion or simply leftover habit from how things used to be.
Take steps to remove these habits from your team.
* Avoiding assigning tasks will give the entire team more of a
collaborative attitude and allow them to approach problems as
they see fit.
* Discuss tasks in a group setting and let individual team members
choose the tasks they want to do.
Tip 5: Don’t Dwell on a Failed Sprint
While you want to avoid it except under the direst of circumstances,
sometimes some facet of the project changes so drastically that
cancelling a sprint is the only realistic option to avoid wasting the
entire team’s time trying to dramatically pivot the work that has
already been done in a very different direction. A sprint can only be
canceled by the Product Owner, though that person should listen to
counsel from the Scrum Master, the Development Team, other
stakeholders or some combination of the three.
Suggested Solution(s)
Once a Sprint fails, it is important not to waste any of the team’s time
and to instead jump into another sprint as soon as things have been
reoriented to prevent the mistakes of the previous sprint from
reasserting themselves. Doing so successfully, without losing
momentum, means managing the framing of the restart in a positive
way. Depending on the amount of time and effort that has gone into
a Sprint prior to its cancelation, it can be perfectly natural for a team
to have a myriad of mixed emotions about it ending prematurely.
This means that in order to ensure the next Sprint starts
successfully, you are going to want to deal with each in turn.
The root of these emotions can be broken into three main issues.
First, it will be difficult for the team to psychologically move past all of
the sunk costs that have been put into place to see the unsuccessful
Sprint to its current state. You will likely see team members who feel
as though the right answer is to instead keep working through the old
Sprint in an effort to salvage something from the previous hard work.
In this case, you are going to want to remind these individuals the
reasons why the Sprint was called off in the first place and
emphasize that everyone is taking what they learned last time and
moving forward with an eye towards not repeating the past.
The second most common type of emotional response is one of
betrayal, a sense that the Scrum Master or Product Owner should
have caught on to the issues that were manifesting themselves at an
earlier point and saved the team from wasting time. The people who
have these sorts of issues with the current state of things are likely
going to question the established Scrum Master and Product Owner
when moving into the next Sprint. If this occurs, the best course of
action is to explain exactly the course of events as they occurred and
what those at the top were thinking and how they were acting
throughout the previous Sprint. Once it becomes clear why certain
decisions were made, dissent should quiet.
Finally, if the canceled Sprint is going to involve undoing or
discarding complicated technical work then it is natural for those who
spent their time creating it in the first place to have something to say
about it. If this is the case, then it is often going to be worth looking
into what of the work can be utilized moving forward as wasting
resources is never the way to achieve a group consensus. Ensure
the agitated party that their previous contributions will be considered
in the context of the new sprint and their reticence should subside.

In Summary
* When restarting a Sprint, it is best to do so as quickly as possible
so that the team does not lose momentum waiting around for
things to change.
* It is important to keep in mind the emotional state of the team for
the best restart results.
* Achieving a team consensus prior to moving on is the best way
to guarantee the next Sprint doesn’t end up in failure once more.
Tip 6: Scrum Masters, Don't Get Too Involved in
Development Team Work
Scrum Masters feeling as though they need to get involved in a
wider variety of tasks is a common issue that can potentially derail
an otherwise productive Sprint. This issue is especially common with
smaller teams where an extra set of hands could really make a
difference at specific points and times. While the urge may be
tempting, it is important to keep in mind that the Scrum Master needs
to be available when the time comes to ensure that Scrum rules are
always being followed as thoroughly as possible. Remember, if the
Scrum Master isn’t aware of what is going on at all times with the
entire team without actually doing the work then they can’t accurately
know when Scrum is or is not being used as effectively as possible.
Suggested Solution(s)
If you are or have a Scrum Master that is feeling pulled in a dozen
different directions at once, then the best way to avoid the Scrum
Master getting too involved is to instead focus on the core
competencies of any successful Scrum Master. First and foremost,
the Scrum Master should be the person who focuses on making all
the various parts of the Sprint proceed as smoothly and efficiently as
possible. Especially early on, this means that the Scrum Master is
going to be spending a lot of time ensuring that the team really
understands Scrum and the benefits it provides. Along these same
lines, they are also going to want to do everything in their power to
ensure that every Sprint meets predetermined deadlines, mainly by
removing impediments (such as those mentioned in this class.)
While a large part of every Sprint is going to be team members
working through problems and challenges on their own as they
develop, throughout this process there are also going to be
obstacles that are encountered that simply cannot be overcome by
the team member who discovered them. This is where the Scrum
Master comes in as it is their job to ensure that these types of
obstacles are removed as quickly as possible to ensure the team
member in question can get back to their tasks without losing too
much time in the interim. Applying yourself as a Scrum Master this
way will yield far better results than rolling up your sleeves and
actually doing the work.
In Summary
* Ensure your Scrum Master knows they don’t need to constantly
be finding work to do within the development team, when it is time
to do something, they will know.
* A good Scrum Master knows how to make every Sprint proceed
as smoothly as possible. Usually this comes from finding and
solving impediments quickly (rather than actually doing the team’s
work)
Tip 7: Keep your Product Owner Involved
A common problem that many Sprints face over time is a Product
Owner who is energized and eager to contribute at the start of the
Sprint, but who then falls off when the time comes to actually turn
ideas into reality. A Product Owner is just as much a part of a Sprint
team as anyone else which means they should ideally be present at
every Daily Scrum as well as during the Sprint Planning Meeting and
the eventual Sprint Retrospective and Review. The Product Owner
will also need to be available during work hours to provide input as
needed to team members with questions. Essentially, when the
Product Owner is not actively dealing with shareholders they should
be involved in the Sprint process.
Remember, the Scrum Team model was created with the express
purpose of being as beneficial to productivity, creativity and flexibility
as possible, but it can only do this when the Product Owner is as
committed to respect, openness, focus, courage and commitment as
the rest of the team. The only exception to this is if your team follows
the strictest, most recent interpretation of Scrum which limits the
Daily Scrum to the development team exclusively. There is still the
option for others to observe the meeting, however and this should
include both the Product Owner as well as the Scrum Master.
Suggested Solution(s)
While early on in your team’s experience with the Sprint, it may be
difficult to determine if your Product Owner is putting in enough time
and effort. You will be able to tell if they added enough input,
however, not only by the amount of communication you have with
them during the sprint, but by how they respond in your Sprint
Review. If, during the Review, the Product Owner uses the time to
provide feedback on the results then you will know they weren’t
involved in the process enough. The sign of an involved Product
Owner is when they are leading the discussion with stakeholders,
users or customers during the Sprint Review instead. They should
have been close enough to the product to know what is about to be
presented in the Sprint Review.
While the Product Owner needs to be as available as possible, there
are numerous different scenarios where they may need to
legitimately be absent from the team for a period of time. First and
foremost, is when they are working with stakeholders, though these
types of meetings should be scheduled separately from Sprint based
commitments in most cases.
In Summary
* The Product Owner is a member of the Scrum team and should
always do their best to act like it.
* The more involved the Product Owner is, the more effective the
Sprint is going to turn out to be, every time.
Tip 8: Don’t Use Stretch Goals
Stretch goals have long been used in many settings as a way of
planning out additional goals that can be reached assuming certain
conditions are met. They are antithetical to the Sprint methodology,
however, and should never be used while on a Sprint for any reason.
A stretch goal is a goal that cannot be achieved by incremental or
small improvements but requires extending oneself to the limit.
There are two different types of stretch goals that can try and creep
into your Sprints, it is important that you are aware of both of them
and where they come from so that the Scrum Master can ensure
they stay away from the positive team-centric attitude that the Sprint
is cultivating. The worst type of stretch goal that can often appear to
ruin group cohesiveness is the stretch goal that is suggested by
someone from outside of the team.
Stretch goals that include a predetermined scope and deadline are
the most difficult for Scrum teams to work through simply because it
requires the team to start with a deadline and a fixed amount of
features, then work backwards to determine how to complete the
work. This is practically the opposite of how things should go. What’s
worse, when objections are raised, they are typically met with either
a reaffirmation to “get it done” or by simply adding more people to
the team which does nothing to improve the state of things if the new
individuals don’t actually know anything about Scrum.
Otherwise, stretch goals have been known to pop up from time to
time when members of the team try and determine what the
Development Team is capable of, despite the Development Team’s
objections. It is important to keep in mind that the Development
Team is going to have the best idea of what it can accomplish given
various external limitations and wasting time disagreeing with them
is, quite simply, time that can be better spent elsewhere.
Suggested Solution(s)
The solution to this common issue is exceedingly simple, let the
team determine the amount of work it can realistically get done
within the confines of the Sprint. That is what the Sprint Planning and
Release Planning meetings are for. This doesn’t mean that the first
assessment of what is going to be done is going to be set in stone,
but it does mean that no member of the team should ever feel
pressured to commit to more work than they feel they can
realistically complete. Forcing a team to commit to stretch goals is
likely to build distrust among team members if the stretch goals are
not met successfully. Distrust can lead to resentment and both will
ultimately result in lower quality work being produced time and again.
After all, if the stretch goal failed then there must ultimately be a
reason why, do your team a favor and avoid stretch goals and the
witch hunts that they will always ultimately engender.
In Summary
* Stretch goals are antithetical to the core concept behind Sprints
which allows team members to set their own workloads.
* Stretch goals can be implemented by individuals outside of the
team or they can be thrust upon certain team members without
their consent.
* Stretch goals tend to break down the cohesiveness that a Sprint
team has built and should be avoided at all costs.
Tip 9: Make it Clear that Individual Sacrifice is Not
Required
When your team is in the middle of a Sprint, they are going to
routinely be forced to work through complex problems on the fly.
There is a right way and a wrong way to solve these problems,
however, and the lines regarding which is which can seem blurry
without the right context. First and foremost, it is important to
understand that the team naturally improves by coming together and
solving these sorts of problems, which not only makes the unit as a
whole more prepared for the future but more cohesive as a team as
well. As such, if one person cracks the nut the entire team was
working on then great, but if that person goes to near super human
lengths to do so, then the team learns a very different lesson
instead.
Rather than learning to work together to solve problems, the team in
this case then learns to rely on the person who they know will always
come through in a pinch. What’s worse, this person could then start
having an inordinate amount of pull over the team as a whole which
means they could end up assigning mandates and even setting
stretch goals without even realizing they are doing so.
They can also cause several other types of issues for the team,
starting with preventing the other members from developing an
ability to creatively experiment and solve problems. If one individual
always has all of the answers then they are robbing others of
learning why certain answers exist, which harms the team as a
whole overall. If this proceeds unchecked for a prolonged period of
time, then it is also likely that certain members of the team will
become apathetic about the process as a whole because it will
quickly become apparent that relying on the star is out of place with
traditional Scrum practices. Ultimately this will break down the
concept of the team at its base level and nothing will be
accomplished, even if the star is still doing everything in their power
to shine.
Suggested Solution(s)
The easiest way to avoid this type of issue is to nip it in the bud
during the planning for the Sprint. As long as things are planned
properly from the beginning, there should be no need for any
individuals to have to step up in any extreme way to get things done.
Additionally, you may find it helpful to pad out your Sprint times with
buffer time. Each task should be planned as if the least experienced
member of the team could take it on. If you find this type of scenario
forming on a regular basis it is especially important to take these
steps so that you can prevent things from devolving towards the
need for such feats in the way they previously have before.
In Summary
* Scrum is all about the team and anyone who carries the team on
their back is ultimately hurting it more than they are helping it.
* If left unchecked, this hero character will ultimately destroy the
team’s effectiveness and cohesiveness.
* As long as the team makes the right decisions in planning prior to
the start of the Sprint, there should be no reason for a hero
mentality to develop.
Tip 10: Avoid Letting the Team Manage the Product
Backlog
During a particularly vigorous Sprint, it is perfectly normal for a team
to come across several additions to the product backlog. Where
trouble arises, however, is when a Product Owner is not involved
enough with the team which leads them to trying to organize the
backlog on their own. Unfortunately, if the team is utilizing Scrum
properly then they likely won’t have all of the information that the
Product Owner has which means that while they can solve technical
problems, they can’t realistically be expected deal with all of the
required logistics at all times.
Suggested Solution(s)
The easiest way to prevent an improperly ordered product backlog
comes in two parts. The first is to ensure that the team has a very
clear idea of the roadmap that they are working from as well as the
requirements that they have to meet. This allows them to clearly
create epicsthat are related to the release. The Product Owner then
checks any epics he did not create and organizes things in order of
importance so that the development team can then tackle as they
see fit.
Product Owner prioritization is going to vary based on several
factors, the first of which is customer priority which is often going to
drive much of the organization process. Additionally, they will need to
consider the need they have regarding the feedback in question,
how long it will take to implement the solution once it has been found
and the amount with which a given feture could improve the ease
with which another feature is completed. Projects in the backlog can
be grouped into either long term or near term items which can give
the team a sense of where it is going now, but also where it will end
up in the future.
While the ultimate decisions are always going to be made by the
Product Owner, these decisions should not be made in a vacuum.
Instead, the best Product Owners are going to take feedback from
the development team in terms of what can realistically be done as
well as designers and, of course, customers. This is not a process
that needs to be done once and then forgotten about, but rather
something that needs to be pruned and trimmed regularly if the team
ever hopes to see real success. As such, the Product Owner should
review the current state of the backlog prior to starting a new Sprint
in order to see the best results. This provides them with the
opportunity to guarantee proper prioritization and add in new
feedback prior to the next Sprint Planning session.
In Summary
* It is important for Product Owners to ensure that they always take
responsibility for managing the product backlog as they have all of
the required information to do so properly and this is their role.
* A well-organized backlog will make it easier for every member of
the team to perform as expected throughout a given Sprint.
Tip 11: Know When an Interruption is Serious Enough to
Warrant Cancelling a Sprint
When a Sprint is underway it is perfectly natural for minor
interruptions to require additions to original estimates. If these
interruptions become more serious as time goes on, however, then
there will come a time when the right choice is to instead cancel the
sprint completely and start over. While getting back into a new Sprint
is recommended in this case, it is also important to ensure that your
team knows just who has the authority to decide that a Sprint is
beyond saving and when they can make that decision.
Remember, agile development is all about successfully adapting to
change, and even doing so to gain a competitive advantage. Good
reasons for the early termination of a Sprint include a dramatic
change for the company as a whole, giving in to external,
unsurmountable market forces, adapting to a new type of
technology, going in the direction of a related major breakthrough,
finding an improved solution to and old problem that bypasses most
of the previous requirements or an urgent round of changes or bug
fixes are required before more work can be completed.
Suggested Solution(s)
While there may be confusion on who has ultimate authority in this
decision, (either the Product Owner or the Scrum Master), the very
nature of the Scrum system, with the Product Owner deciding what
should be worked on next, means that the determination of whether
a particular Sprint is a failure or not is ultimately up to the Product
Owner and the Product Owner alone. While in theory it might make
sense for the Scrum Master, who theoretically has the best idea of
what all the moving parts are currently producing to make this type of
decision, if the Product Owner doesn’t approve then the Scrum
Master’s thoughts on it are not authoritative. This is largely
theoretical, however, in general the Product Owner, Scrum Master
and the remainder of the team are likely to always come to this
decision together as it cannot be an informed decision without all of
their input.
While a Product Owner has the ultimate say in this instance, that
doesn’t mean that they can dramatically realign Sprint objectives on
the fly without expecting negative results. Instead, if a Product
Owner fails to think through all of the required elements of a given
Sprint then cancelling the Sprint completely instead opens the team
up to the possibility of their momentum being permanently altered in
a negative way and overall risks the quality of their work for the
remainder of the project. However, terminating as soon as the need
becomes apparent minimizes additional lost costs and ensures
everyone is on the same page for the new upcoming Sprint.
In Summary
* It is important that no one other than the Product Owner ever
cancels a Sprint once it has been started.
* Starting and stopping repeatedly hurts a team’s productivity both
in the short term and for the length of the product development
cycle in question. Therefore this decision should only be taken if
absolutely necessary.
* A Product Owner should never be afraid to cancel a Sprint simply
because of the costs if it is really the right thing to do.
Tip 12: Do What You Can to Avoid Lagging Sprint Times
While there will always be scenarios that cause initial estimates to be
revised slightly, if your team has several final deadlines that the team
agrees to move back several times to ensure everything is finally
finished to their satisfaction, then you can often expect finish dates to
start lagging even if there is no obvious reason for that to be the
case. This is not the same as individuals who are trying to take on
more work than they can realistically expect to finish, or work that is
more difficult than expected, it is simply a case of the team as a
whole not meeting the sprint deadlines.
Depending on the nature of the work being completed, this type of
attitude can either lead to astounding breakthroughs, or a slow
decrease in work ethic across all sectors. The person who is likely to
have the greatest awareness when this sort of behavior is occurring
is going to be the Scrum Master as they have the option of being
present for every daily Scrum meeting which means they can easily
determine when an individual or group of individuals have been
working on a given task for far too long or slacking on a task.
Suggested Solution(s)
To ensure that this behaviour is naturally curtailed, you need to do is
ensure the team is always using burn down charts as well as holding
demoes, even if your team seems to be making perfect progress. A
burn-down chart can easily show a completed iteration with the tasks
and amount of effort that is likely to be required to get things where
they need to be. It can essentially be thought of as a visual
representation of the amount of work that is still required and how
much time it is likely to take. Ir shows the amount of days in the
sprint on the x axis and the amount if hours of tasks remaining on
the y axis. While a burn down chart will give team members a good
idea of what is expected when it comes to the remaining tasks
related to a specific Sprint, a firm expectation as to when they are
going to have an active demo up and running will ensure that they
have the fire underneath them to cut off deadline creep at the
source. Nothing gets the creative juices flowing like knowing when
you have to show off what it is that you have been doing.
Implementing a strict policy that demos are never moved back baring
major emergency will focus the team on the task at hand.
In Summary
* As teams get more familiar with Scrum, the final deadline period
is likely to experience creep.
* Avoid this by having the team keep a burn down chart so that
everyone always knows exactly what’s left on the current project.
* Keeping originally scheduled Sprint Review (including demo)
dates will ensure everyone stays on track throughout the Sprint.
Tip 13: Properly Prepare for All Sprint Reviews and
Demos
If your team is just getting used to the Sprint process, or if the project
they are currently working on proves to be more challenging than
they first expected, the Sprint that is currently taking place can hit a
snag when it comes time to actually demonstrate its actual results in
the Sprint Review. This can be a potentially disastrous outcome,
however, as without the proper planning a demonstration can only
lead to questionable value and a confusion of its core purpose or
function.
Suggested Solution(s)
Remember that it takes time to prepare for the demonstration, clean
the team workplace and set up a demonstration environment that
mimics real life potential usage cases. Additionally, the team needs
to budget time to decide on what to say and how to properly prepare
key stakeholders for the presentation they are about to see. If your
team routinely has trouble being properly prepared when it comes to
the demonstration phase, the Product Owner might find it helpful to
include a separate user story in the Product Backlog for the
demonstration preparation period.
Alternatively, this problem may occur if the planning phase for the
Sprint in question proved to be extremely chaotic with much of the
team curious as to the ultimate end goal their work might lead to. If
this is the case, then what is likely required is simply a clearer Sprint
goal overall. If the overall goal for the Sprint in question is clear from
the start then the Development Team and the Product Owner are
more likely to be on the same page, which will lead to a more
focused experience overall. A clear sprint goal will specifically
determine the team’s end goal as well as the time table for doing so.
This framework inherently takes the demonstration into account
because it also says what is ultimately going to be demonstrated and
when it going to be done. Once the Product Owner has made it clear
what they want, the team can work out the ways to give it to them
before reconvening to ensure that everyone is on the same page.
This further ensures that the demonstration is going to go smoothly
because the information that is going to be delivered in that setting is
going to be the same as what is discussed by the team beforehand.
This meeting should also include the basics of what the
demonstration is going to entail so that it is constantly be worked
towards instead of simply cobbled together at the last minute based
on what the completed work ended up leaving available.
Furthermore, it should discuss and other costs or potential issues
that the demonstration might entail so that it can be account for as
early as possible.
In Summary
* Nothing can send an otherwise successful Sprint spiraling than a
poorly planned demonstration.
* The preparation for the demonstration can be added to the Sprint
backlog if your team works better that way.
* Alternatively, your team might find more success if they instead
plan out the demo during the Sprint planning stage prior to starting
the work related to the Sprint itself.
Tip 14: Ensure you Create Potentially Releasable
Products
During a Sprint, the end goal is always to generate an increment of a
potentially releasable product. What that means however, can be
different for different teams based on the requirements put forth by
the Product Owner. Regardless, by speeding up the initial rate of the
creative process, ending the Sprint with a potentially shippable
product helps to put the product into the hands of the consumers or
other key stakeholders as quickly as possible which makes
additional improvements and iterations much more easy to come by
than they might otherwise be. This is why creating a potentially
shippable product is so useful, it allows the team to benefit from this
feedback loop at the end of each Sprint during the Sprint Review.
Suggested Solution(s)
Remember, Scrum is simply a framework that emphasizes
ceremonies and principals over a precise methodology which means
that in order to find success each team must individually decide how
to leverage the principals in question within the context of their own
team. While the strict definition of success or failure will be up to the
team in question, a good rule of thumb is for the team to always work
with the production code and try and find the answers there as
opposed to starting with a prototype code and then wasting extra
time copying it to the production code once if finally starts working.
The same goes for wireframes and other related tools, if your team is
going to have to double up on their output in order to use it properly,
it isn’t worth the extra time investment no matter how complex the
code in question is.
In order to ensure that the team is likely to finish each Sprint with a
new potentially shippable product, they are going to need three
important things. The first of the three crucial factors to creating a
potentially shippable product is ensuring that the team is as cross-
functional as possible (i.e. they consist of all the skills necessary but
work together for a common goal) which will provide them with the
ability to most definitely tackle the next product in the Product
Backlog. A cross functional team is a team where individual
members have primary tasks and responsibilities but they are also
capable of handling additional tasks from other parts of the team if
the situation requires it. Additionally, the team is going to ensure they
understand the acceptance criteria of each user story at sprint
planning so that they can create a high quality product during the
sprint. Finally, the team is going to need a Product Owner and Scrum
Master who know how to properly answer any questions and remove
any impediments that come up during the sprint planning or sprint.
In Summary
* Finishing each Sprint with a Potential Shippable Product is key to
maximizing the effectiveness of each Sprint.
* Ensure your team are working cross-functionally so that team
members combine to complete any story in the backlog
* Make sure that the development team understand the
acceptance criteria at sprint planning so they can create a high
quality product
* As a Scrum Master, do your utmost to remove impediments and
as a Product Owner, do your best to answer any questions the
team may have during the sprint planning and sprint
Tip 15: Do What You Can to Keep the Team Intact
Scrum is about building a productive team unit, not about training
individuals. As such, if the membership of a team changes even a
single individual then any work that has already been doing whether
it is forming, storming, norming or performing, is likely going to be
rendered largely useless. This is especially true if the team has
already made it to either the performing or norming stages and also
represents a significant waste of an investment as well. If you hope
to complete your current sprint inside the original specifications, then
you are going to want to do everything you can to keep your team
intact for as long as possible.
Suggested Solution(s)
If you are unsure if your team is in a group state where you won’t
lose much when adding or subtracting individuals, it is important to
keep in mind what stage of group development the group is currently
in. If the group is currently still in the formation stage, then new
members can be added or subtracted without doing much damage to
the group dynamic as a whole. During this period, the roles of
individuals in the group have yet to be defined and the processes
that the team uses to get results have not yet been determined.
If the team has already made it to the storming phase of group
development, then they are likely coming to a general consensus on
how future decisions are going to be made. Depending on the
consensus that was reached, certain individuals can still be added or
subtracted to the group without starting over as long as the new
individuals don’t rock the boat too much with their arrival.
Relationships are still typically somewhat blurry at this point which
means that things could still change before they have settled into
more of a finalized form.
If the team reaches the norming stage, then you are only going to
want to make changes if there is no other way around doing so. This
change will likely send the team back to the storming phase, but
depending on who was removed, the norming phase should return
relatively quickly. During this phase the relationships between
individual team members should be pretty well solidified and
understood by the group as a whole. The individual members are
also likely going to be experiencing feelings of increased
commitment and dedication to group goals. The team is also likely to
begin optimizing processes at this point, changes should definitely
be made before this point to avoid too much wasted effort.
Finally, if the team has made it to the performing stage, then any
changes can dramatically alter the makeup of the group dynamic
which is why it should only be undertaken in extreme circumstances.
If the team has reached the performing stage then they are likely
performing well together, focusing on improving their strategy and
running well based on the natural strengths of the team.
In Summary
* The team dynamic in a Sprint is extremely important and should
only be tinkered with if there is no other option to be found.
* If the team has reached the performing stage, you should do
everything you can to keep them together.
* Teams can be reformed most easily during the forming or
storming group development phases.
Tip 16: Avoid Imposed Limitations
As a whole, Scrum is a system that is inherently reality based which
means that individuals provide realistic estimates of how long given
projects will take. As such, when the needs of a stakeholder outside
of the team start to influence either deadlines or the resources
available, then the Sprint that is currently taking place is going to
begin to break down as well. By its very nature, a Sprint that is
limited in terms of the timeframe that it has to work with or by the
resources that it has available in the moment is going to turn out
inferior quality results which goes against the core tenants of the
Scrum system.
Suggested Solution(s)
Due to the very nature of the Sprint itself, accurately predicting the
final details surrounding it in terms of costs or time is practically
impossible and the idea that stakeholders who are not directly
involved in the team would have anything can predict this is a
fantasy. As such, the best way to improve this outcome is to ensure
that stakeholders are educated properly when it comes to deciding
what the team is thinking. For starters, this means taking the time to
explain to them the timetable related to the Sprint in question as well
as the estimated costs. Doing so will make it much easier for them to
understand where various relevant details have come from which
will, in turn, hopefully make them more agreeable to the information
that the team has come up with. The Sprint Review is a great place
to show stakeholders a sprint plan of where the progress currently
lies, which stories have been completed and which stories are
planned for future sprints. However, it must be made clear that this
is not set in stone.
Additionally, if you present them with a clear plan of action regarding
the product in question, then it will make them more likely to add any
suggestions for changes or additions they might have to the realm of
future Product Backlog material instead of something they decided to
add on to the current Sprint, dramatically improving the current
Sprint’s chances of success in the process. What’s more, sometimes
they simply want their ideas heard. If these ideas are feasible,
adding them to the backlog is an easy way of doing that without
directly committing to please them.
If, after the plan has been explained, the stakeholders are still trying
to impose limitations or additions on the team, then the best thing to
do is explain the cost of their imposing to the project in terms of
diverted time and resources.
In Summary
* Keeping stakeholders’ imposed limitations and additions to the
team to a minimum is key to finishing a Sprint successfully
* The easiest way to do this is to actually educate outside
stakeholders in terms of what the current timeline for the Sprint or
release is and how that timeline was determined.
* When in doubt, ask the stakeholders what they would prefer to
be dropped in exchange for adding their demands to the current
Sprint.
* Always explain the cost of the stakeholders imposing their will on
the team
Tip 17: Know What ‘Done’ Means in Context
Regardless of how well a team has planned out their next Sprint,
things can always start to go wrong if various stakeholders start
throwing around standards while at the same time talking about them
as though they were the definition of ‘done’ itself. This is often an
easy mistake for them to make, however, as the ‘definition of done’
has a very specific meaning when it comes to each current Sprint.
Suggested Solution(s)
This issue can be easily fixed by simply ensuring that everyone’s
definition of done (DoD) lines up properly. Every team should create
a definition of what constitutes a ‘done’ increment of a product. This
should be created at the beginning of a project and evolve as
needed through the course of the project. Typical examples of things
in the DoD are ensuring that automation tests are passing or that the
product increment is in line with the designs.
When the team are planning, they will usually include each activity
that they need to finish in order to create software for the features in
the Product Backlog, this will likely include many common things like
creating a way to login to the service, generating unit tests and
rewriting code. During this period many common tasks are going to
appear again and again and again, these should instead be added to
the Sprint Backlog. This could be things like creating an international
version of various software. In this example, the phrase
internationalize would then become abstracted and ensuring
everything is properly internationalized becomes part of the definition
of done. After a task has been added to the definition of done, it
doesn’t need to be added to every separate task list, it becomes part
of its own master checklist that will be verified near the end of the
Sprint when it can be actively checked off for the final time.
The DoD can then be used for all sorts of things that the team deem
necessary. This way they can all be collected and slotted into
available time in the existing Sprint, not prioritized over the work that
is already being done. However, it is important that the things that
are added to the DoD only when the team agrees that they are an
important and frequent part of the work that is currently being done.
Remember, a DoD item needs to be done during every Sprint if that
Sprint is going to be considered a success.
If the team doesn’t feel as though they have the manpower or skills
to successfully complete the DoD items that then it is up to the
Scrum Master to see what can be done in terms of training or liaising
with third parties to ensure that the DoD can be met. Remember that
there is no point in adding things to the DoD unless they are actually
achievable.
In Summary
* Having a definition of done is key to Sprint success.
* Taking the time to make sure all of the team members are on the
same page when it comes to the definition of done items on the list
is crucial to accurately managing their expectations.
* If the team cannot meet a desired item in the definition of done
due to lack of skills, the Scrum Master should take this on as an
impediment to be solved
Tip 18: Get Familiar With Your Users
No matter how well intentioned a Sprint might be, it is certainly
doomed to failure if the team is not focusing on the right users and
therefore is focussing on the wrong user stories. The best user
stories are those that clearly and concisely explain a certain type of
functionality. The clearer the relationship between the user and the
product is, the better.
Suggested Solution(s)
If your team is still trying to get a clear idea of its user base, then the
best way to start is with research on the type of users that the team
plans on courting. This is something the Product Owner is
responsible for and can be done by looking through existing data or
by simply interviewing and observing users similar to those you know
the end result will ultimately be targeting. It is important to hold off on
writing user stories until you have a perfectly clear picture of a
product vision and an ideal user in mind.
Once you have a clear idea of the target group that you are hoping
to cater to, the next thing you are going to want to do is create a
number of different personas that are generated based on the
information on the target group that you have found. Each persona
should have a name as well as a general profile that includes end
goals, attitudes, behaviors and characteristics that makes them
unique from the other personas. The end goal here should be to
shine some light on the type of problems that a person who is similar
to a given persona might come across.
Many of the best user stories are often created by not just a member
of the team, but by the team as a whole. Stories that are created in
this way tap into a greater wealth of knowledge and experience and,
as such, are always going to be stronger because of it. Additionally,
the best results are always going to come from collaborations
between the team and the Product Owner. Likewise, they should
never just be handed off to the Development team, they should be
discussed in conversation to give them a fuller and more well-
rounded personality in addition to just a simple motivation. This can
be done as part of the grooming of the Product Backlog which further
leverages the knowledge and creativity of the entire team to
generate more fully fleshed out results.

In Summary
* Having a clear idea of who their end user is going to be should
be one of the first things that every new team defines for
themselves. This is the responsibility of the Product Owner.
* Collaborating with the team to determine various types of users
and the usage scenarios they might encounter is encouraged for
the best results.
* A Product Backlog Grooming meeting is a great place to drive
out further detail about users and user stories as a Scrum team.
 Tip 19 – Discuss Features with Product Owner before
the Actual Sprint Review Meeting

It is a well known agile principle that every feature should be

discussed with the product owner before, during and after its
completion. This is known as the principle of card, conversation and
completion (the three Cs). Also, with the product owner expected to
attend the Sprint Review Meeting, he should know just as much as
the Scrum Team does before they discuss progress with the
stakeholders.

Suggested Solution(s)

Although all members of the development team are encouraged to

present to stakeholders during the Sprint Review Meeting, it is the
product owner who serves as the key ambassador for the product
between the stakeholders and those who are responsible for putting
the product together. It would therefore be embarrassing for the
Scrum Team if the product owner does not exhibit any familiarity with
how the product is doing and is only learning about it at the same
time that the stakeholders are.
Although it does not immediately guarantee that all previously
identified Features will be declared “done” by the end of the Sprint
Review Meeting, the meeting itself will be more streamlined if the
product owner already has an idea of the state of the latest iteration
of the product just before they make their presentation. Thus, a
Scrum Team is highly encouraged to discuss every feature with the
product owner and demo it before the sprint review. Otherwise, if the
product owner has to spend precious minutes of the Sprint Review
Meeting trying to understand where the team is in terms of their
progress, they would not have enough time listening to stakeholder
feedback and establishing new Features in response to such
feedback.
Another more important reason is the “Three Cs Principle”. This
suggests that:
1. Card - a team member should read the user story card with
acceptance criteria and understand it
2. Conversation - the team member should discuss what he has
read with the product owner to iron out any potential
misunderstandings
3. Confirmation - once the feature is complete, the team member
should actually demo it (albeit informally) to the product owner to
confirm that it is done.
This is a best practice for a quality product and will save a lot of
issues in the sprint review.
There’s another key reason for having a demo with the product
owner before the actual Sprint Review Meeting: it gives the Scrum
Team a safe environment for a dry run in which they could
confidently practice giving their presentation to the stakeholders.
This will also help the Team identify and retain only those user
stories that are sure to encourage thoughtful discussion during the
Sprint Review Meeting. And yes, even Features that may not yet be
declared “done” may be presented, as long as the Scrum Team and
the product owner believe that doing so will result in meaningful
feedback. Everything else can be discarded so as not to waste
people’s time.

In Summary
• The product owner has to be familiar with the latest iteration
of the product prior to making it to the Sprint Review Meeting.
• The Three Cs principle informally actually helps teams
prepare for a sprint review
• Conducting a dry run with the product prior to the actual
Sprint Review Meeting allows the Scrum Team to identify the
stories that are sure to elicit feedback from the stakeholders.
Tip 20 - Use Roundtable Discussion In Retrospectives

Every person has his or her own unique way of looking at things.
What you might have thought of as brilliant might seem lame to
another person. However, it is very important that every person is
given their own space where they do not have to hinder while
expressing their opinions and suggesting ideas. When in a team,
providing such opportunities really matters!
Suggested Solution(s)
Let's say you have got an idea in mind which you think will work
wonders for your team during the retrospective. But you seem to
hesitate putting out your ideas because you feel there would be
people who disagree with you and oppose your ideas. When this
happens, the idea is killed without even knowing if it would really
work or not. This is what usually happens during group discussions.
Members might feel reluctant in expressing their views as others
would be ready to criticize it in a group discussion. This must be
avoided at wherever possible. The facilitator must provide
opportunity to every single team member to speak without any group
discussion. This will ensure the members that no-one else will be
allowed to comment or criticize their opinion. During this time, only
questions of clarification must be allowed. Discussion could be done
later after the person has successfully put out his or her idea.
I call this a roundtable discussion because each person sitting at the
table is guaranteed an opportunity to speak. This is my personal
favourite method and the one I have used successfully with most
teams.
In Summary
• Every person has unique ways of approach and ways of
tackling a problem
• The team member may hesitate to put out his or her idea
during a group discussion fearing criticism
• The facilitator must ensure that every member gets the
chance to speak and a roundtable discussion can help ensure
that free flow of thoughts occurs.
Tip 21: Make The Best Use Of Team Time At The End Of
A Sprint
While the goal of every sprint should be to generate working
software, the way that free time is handled can easily determine the
long term success or failure of any product, and thus all of the
Sprints in between.
Suggested Solution(s)
While it is true that software that is not yet fully up and running is
considered a failure, it is important to ensure that the final hours of
the final days of a Sprint are still used constructively, even if they
aren’t being actively used to complete leftover work on the existing
Sprint. Instead, if a team member has nothing they can currently
contribute further to the current Sprint, then it is important to make it
known that it is perfectly acceptable to start thinking about the big
picture when it comes to the Sprint that is coming up next.
While it often won’t amount to much, having a few individuals who
are actively thinking about what’s coming next, especially when there
isn’t anything they can realistically do to help contribute to the overall
success of the current Sprint can ensure that the Sprint after this
Sprint is going to get started on the right foot. This is yet another
reason why it is important to have an active Product Owner and a
well-groomed Product Backlog so as to assure that every minute that
a team is working on a Sprint is productive to the product as a whole,
if not necessarily the Sprint that is taking place right this very
second.
When promoting this type of work ethic, it is especially important to
ensure that it is clear to the team that it is only acceptable once they
have nothing left to positively do on the Sprint in question. Looking to
the future is an admirable trait in a team and one that should be
nurtured, just not at the expense of the results that manifest
themselves in the short term. Above all, the successful completion of
the current Sprint should always reign supreme.
In Summary
* Unfinished work at the end of a Sprint can be beneficial, in a
specific and limited set of circumstances.
* Keeping a well-groomed Product Backlog can easily ensure that
every team member always has a productive way to spend their
time.
* For this to work you need to make it clear that work related to the
current Sprint is priority one.
Conclusion
This class has equipped you with a wealth of information to enable
you to go on your scrumming journey with confidence. You have
learnt many tips that will prove useful as you practice Scrum, but as
useful as the advice here may be, nothing is as important as
implementing the tips and strategies you have learned here.
Implement these pieces of advice and go for it with all you have.
Happy scrumming.
Thank you again for taking this class!
I hope this class was able to help you to improve and master agile
scrum.
The next step is to start putting into practice what you have learned.
All the greatest practitioners achieved their goals by putting tips such
as these into practice and learning from their experiences. You can
do it too!
You can get more information at www.freescrumebook.com

Finally, if you enjoyed this class, would you be kind enough to leave
a review?

Click here to leave a review for this!

Thank you and good luck!

Resources
https://www.mountaingoatsoftware.com/agile/scrum/product-owner
www.innolution.com/val/detail/product-owner-day-in-the-life
https://www.linkedin.com/pulse/day-life-product-owner-scott-gibson
https://msdn.microsoft.com/en-
us/library/hh765980%20(v=vs.120).aspx
http://www.romanpichler.com/blog/new-product-development-with-
lean-startup-and-scrum/
www.romanpichler.com/blog/the-product-vision-board/
https://www.scrumalliance.org/community/articles/2009/january/the-
product-vision
https://dzone.com/articles/working-product-vision-board
www.romanpichler.com/blog/working-with-the-agile-product-vision-
board/
https://www.mountaingoatsoftware.com/agile/scrum
https://www.scrumalliance.org/why-scrum
http://www.scrumhub.com/what-does-a-scrum-master-do-all-day/
https://www.mountaingoatsoftware.com/agile/scrum/product-backlog
www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-
step-1-get-your-backlog-in-order/
www.scrum-institute.org/The_Scrum_Product_Backlog.php
https://www.mountaingoatsoftware.com/agile/user-stories
https://www.cprime.com/resources/what-is-agile-what-is-scrum/
www.agilenutshell.com/
https://www.mountaingoatsoftware.com/blog/make-the-product-
backlog-deep
https://www.mountaingoatsoftware.com/agile/scrum/release-
burndown
www.enfocussolutions.com/the-three-c-s-of-user-stories/
https://www.mountaingoatsoftware.com/agile/scrum/task-boards
http://www.scrumcrazy.com/How+I+Classify+Coaching+Advice
Preview of ‘ The Scrum Master Mega Pack ’
This book is an amalgamation of the following books sold as a cost
effective box set (so be sure not to buy them again):
1. Complete Overview of Scrum - The Power of Scrum, In the Real
World, For the Agile Scrum Master, Product Owner, Stakeholder and
Development Team
2. 72 Reasons Why Scrum Works, For the Agile Scrum Master,
Product Owner, Stakeholder and Development Team
3. The Scrum Checklist, For the Agile Scrum Master, Product Owner,
Stakeholder and Development Team
4. Scrum of Scrums, Agile Programme Management, For the Agile
Scrum Master, Product Owner, Stakeholder and Development Team
5. Scrum Top Tips, For the Agile Scrum Master, Product Owner,
Stakeholder and Development Team
6. How to Become a Scrum Master, In 7 Simple Steps, For the Agile
Scrum Master, Product Owner, Stakeholder and Development Team
7. How to Meet a Project Deadline with Scrum, In 7 simple steps For
the Business, Agile Project Manager, Scrum Master, Product Owner,
and Development Team
BONUS
8. Kanban, The Kanban guide, For the Business, Agile Project
Manager, Scrum Master, Product Owner and Development Support
Team
Here is a piece from the book:
6 reasons why SPRINT PLANNING works
Background
The sprint planning session is a meeting in which the team plan and
commit to the stories that they will work on in a sprint. The meeting
lasts no more than four hours for a two-week sprint. There are two
halves to the meeting, the “what” and the “how”. In the first half of the
meeting, the product owner presents the list of features that he
would like the team to deliver from the product backlog. He explains
them and the team ask questions. In the second half of the meeting,
the team break the stories into technical tasks and estimate them.
The meeting ends with a commitment from the team to complete the
sprint backlog within the sprint.
Reasons
1. The planning process gives solid understanding: As opposed to
other methods, it is the act of discussing and understanding the
proposed sprint backlog that gives the team a solid understanding of
what they are building. There is no reliance on a document to do
this.
2. Expert estimates: The estimates given at planning are from the
most reliable source possible – those doing the work, as opposed to
a single team lead.
3. Reliable estimates: Rather than individual estimates, the shared
view of the team is reflected in the estimates. This is a more reliable
view since it takes into account all perspectives.
4. Motivating, enjoyable experience: Planning gives a chance for
people to interact and to some extent socialize. This is usually seen
as an enjoyable experience as long as it is strictly timed and
especially if planning poker is used as a technique (doughnuts also
help greatly).
5. Product closer to customer desires: The product owner brings the
business view to the session and the team bring the “builder's” view.
This results in a product much closer to what the customer desires.
6. Strict time-box keeps morale high: The time-boxed session must
run to a strict time scale. A further session can be planned if
absolutely necessary, but this strictness prevents fatigue.
Click here to check out the rest of (Scrum Master Mega Pack) on
Amazon.
Or go to: http://www.amazon.com/dp/B00988FMU8
Check Out My Other Books
Below you’ll find some of my other popular books that are popular on
Amazon and Kindle as well. Simply click on the links below to check
them out. Alternatively, you can visit my author page on Amazon to
see other work done by me.
The Power of Scrum, In the Real World, For the Agile Scrum Master,
Product Owner
Confessions of a Scrum Master, for the Agile Scrum Master, Product
Owner, Stakeholder and Development Team
Kanban, The Kanban guide, For the Business, Agile Project
Manager, Scrum Master, Product Owner and Development
How to Become a Scrum Master in 7 Simple Steps (Agile Project
Management)
Scrum of Scrums, Agile Program Management, For the Agile Scrum
Master, Product Owner, Stakeholder and Development
Scrum, The Complete Overview and Guide (Boxset), For the Agile
Scrum Master, Product Owner, Stakeholder and Development
The Scrum Checklist, For the Agile Scrum Master, Product Owner,
Stakeholder and Development Team
How to Meet a Project Deadline with Scrum In 7 simple steps For the
Business, Agile Project Manager, Scrum Master
Scrum Top Tips, For the Agile Scrum Master, Product Owner,
Stakeholder and Development Team
Selling Scrum to the Business: 72 Reasons Why Scrum Works, For
the Agile Scrum Master, Product Owner, Stakeholder
Scrum, (Mega Pack), For the Agile Scrum Master, Product Owner,
Stakeholder and Development Team
If the links do not work, for whatever reason, you can simply search
for these titles on the Amazon website to find them.
Bonus: Subscribe to Download the Free Scrum Ebook and
Bonuses
When you download the Free Scrum Ebook and subscribe to get the
free bonuses via email, you will get free access to a some of
exclusive subscriber-only resources. All you have to do is enter your
email address to the right to get instant access.
These exclusive bonuses and resources will help you get more out
of agile scrum – to be able to reach your agile scrum goals quicker
and faster than ever before like the pros. I am always adding new
bonuses and discounts as well, which you will be notified of as a
subscriber. These will help you to achieve your goals as quickly
as possible!

Here are the details of what you will learn:

The Number one Reason why projects succeed or fail, which is
key to your success going forward.
How Agile relates to Scrum one of the most confused topics in
industry
A complete introduction to Scrum theory, the foundation of it's
success as the theory will give you a strong foundation going
forward
An overview of all the Scrum rules so that you can set the correct
framework for your projects
A complete understanding of all the Scrum roles as these make
scrum so powerful
An overview of all the Scrum events so that you have a summary
of all the practices the pros use
How you can take steps to get your project to the next level so
you know what to do next
Access to my blog including:
Regular lessons on how to improve scrum events
Discounts of up to 99% on all my scrum courses
To get instant access to this free scrum ebook and more
incredible bonuses and resources, click the link below:
Click here for the FreeScrumEbook and Bonuses.
Or you can access it here: http://www.freescrumebook.com