For Impetus’ White Papers archive, visit- http://www.impetus.com/whitepaper Mistakes by Scrum adopters, in tweaking or avoiding defined Scrum rules, can result in the reduction of the benefits offered by Scrum practices. Scrum practitioners need to adhere to Scrum rules and avoid customizing the practice.

1. 10 Mistakes to Avoid in
Scrum
Abstract
Mistakes by Scrum adopters, in tweaking or avoiding defined
Scrum rules, can result in the reduction of the benefits offered
by Scrum practices. Scrum practitioners need to adhere to Scrum
rules and avoid customizing the practice.
Impetus Technologies Inc.
www.impetus.com
W H I T E P A P E R

2. 10 Mistakes to avoid in Scrum
2
Table of Contents
Introduction...........................................................................................................3
10 mistakes to avoid..............................................................................................3
Case Study..............................................................................................................6
Summary................................................................................................................7

3. 10 Mistakes to avoid in Scrum
3
Introduction
Scrum adopters tend to bypass Scrum rules as they are more familiar and
comfortable with traditional methodologies. In order to make the process more
convenient for them, they sometimes tweak Scrum rules and create their own
version of the Scrum practice. However, these mistakes cost them as they lead
to a reduction in the benefits offered by Scrum.
Some of these mistakes not only impact the productivity and efficiency of the
team, but also reduce its synergy. Scrum rules have been defined to make the
process more effective for the team, which is why the team and management
executives must strive to enhance the practice and achieve the maximum
benefits.
This white paper highlights some of typical mistakes that Scrum adopters make
their causes, impact, and the ways in which they can be avoided and corrected.
10 Mistakes to Avoid
1. Incomplete User stories and lack of Backlog grooming
Defining User stories with complete details is the factor of time and
intention. Sometimes, product owners and team members are so engaged
in their current Sprint work that they overlook the backlog grooming
process and the preparation for the next Sprint. The leads to more time and
effort being spent during the next Sprint. Product owners sometimes
believe that the work for a particular User story is so intuitive that no
additional details are required. They then refrain from completing its
details. However, this can result in confusion and unexpected results at a
later stage.
To avoid any potential confusion for the Scrum team, it is essential that User
stories have the complete details and that backlog grooming is regularly
practiced to uncover any hidden details.
2. Estimating the User story size based on effort estimation
Although the Scrum practice does not give a lot weightage to accurate
estimation of the User story, it is important to determine its appropriate
size to understand the velocity and productivity of the Scrum team. As User
stories are estimated in arbitrary units like User story points, Scrum

4. 10 Mistakes to avoid in Scrum
4
provides a platform to compare two User stories and determine the team’s
efficiency in implementing them.
It has been observed that some teams use the estimated efforts to
determine the User story size. This practice not only varies the size of the
User story based on the team’s efficiency, but also makes it more difficult to
determine the change in the team’s productivity with time.
The use of the ‘caparison’ method is recommended for determining the size
of the User story. It suggests that size be determined by comparing the
current User story with the previous ones that have been similarly
deployed. Initially it is difficult to determine the size, but becomes easier
with experience.
3. Introducing work scope changes in the middle of the Sprint
This is a very common mistake which can be disruptive for the team. There
may be some practical reasons which invite the changes, but these can
impact the planned commitments for the Sprint. They can also sometimes
demoralize team members.
The scope of the work should be locked down for a Sprint and any changes
in the middle of the Sprint should be discouraged. If product owners believe
there are higher priority User stories, they can cancel the current Sprint and
start a new one with an updated Sprint goal.
4. Shuffling team members in the middle of the Sprint
Organization dynamics make changes inevitable, but they can impact the
planned deliverables for a Sprint if introduced in during its course.
Shuffling team members makes collaboration difficult within the team and
causes confusion.
All team members for a particular Sprint should be locked down and
changes avoided in the middle of the Sprint. If the changes are unavoidable,
product owners can cancel the current Sprint and start a new one with
updated Sprint goals.
5. Spilling over incomplete work to the next Sprint
Sometimes, the Scrum team tries to move the incomplete User stories to
the next Sprint as they may not be complete in all respects. It can be the
result of poor or no backlog grooming, but defeats the purpose of Scrum to
deliver the ‘potentially shippable’ product.

5. 10 Mistakes to avoid in Scrum
5
First of all, it is very important to define the meaning of ‘Done’ for the team.
Any User story, planned for a particular Sprint, should be complied with
‘Done’ by the end of the Sprint. If there are any exceptions, product owners
hold the right to accept or reject the work. But, these exceptions should be
avoided or minimized in order to provide better predictability and visibility.
6. Not following Scrum ceremonies as prescribed
Some Scrum teams try to alter the formats prescribed by the Scrum practice
by changing the agenda or deviating from the time limits. This can result in
reducing the productive time available to the team. Moreover, sometimes,
certain ceremonies are missed in the Sprint.
The recommended formats for Daily Scrum, Sprint Planning, Sprint
Retrospective and Sprint Review are defined to make the maximum use of
the time and avoid any other potential requirements for unnecessary
meetings. It is therefore suggested that the Scrum ceremonies be followed
in their prescribed format in order to gain the most benefits.
7. Playing by hierarchy of the team structure
Scrum defines all team members as ‘Developers’ and recommends not
having any titles. However, most of the organizations have a hierarchical
structure and titles for employees. This hierarchical structure sometimes
becomes a hindrance to collaboration. Moreover, team members also get
influenced by non-Scrum members as they report to them, which may result
in a deviation from the Sprint goal.
All team members may be playing different roles, but they are at the same
level in the Scrum team. Therefore, ego clashes should be avoided. Any
changes suggested by non-Scrum members should be first discussed with
the Scrum Master and product owner, who can then communicate them to
the team. The Scrum Master should protect the team from any outside
impacts.
8. Distinction of roles among cross-functional team members
The Scrum team consists of cross-functional team members playing
different roles. But, sometime, they are so rigid about their roles that they
do not want to cross their functional boundaries. For example, some
programmers say no to test the User story. It may result in the Scrum goal
not being met.
The Scrum team may consist of cross-functional team members, but they all
work to meet the Sprint goal. It may require them to wear different hats as

6. 10 Mistakes to avoid in Scrum
6
the situation demands, which means that team members should be
groomed to play any required role as needed.
9. Trying to match up the estimated task hours ignoring actuals
Team members estimate their task efforts based on their assessment of the
User story work in the Sprint planning meeting. However, as they go along,
they might experience the deviation between estimated and actual effort. It
may drive team members to start tweaking actual hours to make them close
to the estimated ones. This practice blurs the shortcomings and
improvements required in task estimation.
Team members should be groomed and prepared for the fact that the
difference between estimated and actual task efforts can happen. They
must understand that this provides them with the opportunity to examine
the situation in retrospect and improve on the task estimation.
10. Working without a Sprint goal
The Sprint goal is the outcome of a Sprint planning meeting and defines the
objective for the Sprint work. If the goal is not met at the end of the Sprint,
the product owner can actually reject the Sprint work. However, some
teams overlook the concept of the Sprint goal and do not define it for the
Sprints. Without this, it is difficult to weigh the success or failure of the
Sprint.
The Scrum goal should be stated in terms of recognizable (usually, working
software) outcomes. The goal helps team members to recognize what is
important when weighing options during the Sprint. It usually represents
the minimum functionality to be delivered.
Case Study
The challenge
We observed in one of the engagements that the Scrum team members
were deviating from the hierarchy they reported to. This was occasionally
going against the goal of the Sprint. It was causing confusion among team
members regarding the expectations and priority of their tasks. It was not
only impacting the commitments for the Sprint, but also demoralizing team
members.
Solution offered

7. 10 Mistakes to avoid in Scrum
7
The first step for Impetus was to negotiate and publish a working
agreement between the Management and the Scrum Team. The most
important task was to ensure that managers did not meddle with the
priorities within the Sprint, and that the team provided a full transparent
daily status. Managers were allowed to influence the priorities of the next
Sprint by negotiating with the product owners. They were invited to Backlog
grooming activities if they had a legitimate stake in the priorities.
The second step was to introduce an internal service desk for the managers,
including department managers and upper managers, and convince them
about the important of using the service desk to submit their requests. This
allowed us to manage these request from outside the Scrum team.
Summary
The Scrum practice has defined the rules for Scrum teams to follow and allowed
them to choose their own operational strategies. Following prescribed Scrum
rules makes things more efficient and disciplined. Altering these rules may
provide short-term gains, but may result in disadvantages in the longer run.
About Impetus
Impetus is a Software Solutions and Services Company with deep
technical maturity that brings you thought leadership, proactive
innovation, and a track record of success. Our Services and Solutions
portfolio includes Carrier grade large systems, Big Data, Cloud,
Enterprise Mobility, and Test and Performance Engineering.
Website: www.impetus.com | Email: inquiry@impetus.com
© 2013 Impetus Technologies, Inc.
All rights reserved. Product and
company names mentioned herein
may be trademarks of their
respective companies. May 2013