10 mistakes to avoid in Scrum

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 April 2012

..... but also reduce its synergy................................ 2 ......................... 7 Introduction Scrum adopters tend to bypass Scrum rules as they are more familiar and comfortable with traditional methodologies.. This white paper highlights some of typical mistakes that Scrum adopters make their causes................... 2 10 mistakes to avoid .............. In order to make the process more convenient for them........ However. Some of these mistakes not only impact the productivity and efficiency of the team.................. which is why the team and management executives must strive to enhance the practice and achieve the maximum benefits....................................... Scrum rules have been defined to make the process more effective for the team..................................... impact....................... 6 Summary ..... 3 Case Study.10 Mistakes to avoid in Scrum Table of Contents Introduction . they sometimes tweak Scrum rules and create their own version of the Scrum practice................ these mistakes cost them as they lead to a reduction in the benefits offered by Scrum.................................................................................................................................................................. and the ways in which they can be avoided and corrected............................

this can result in confusion and unexpected results at a later stage. However. 3. It suggests that size be determined by comparing the current User story with the previous ones that have been similarly deployed. but becomes easier with experience. 2. It has been observed that some teams use the estimated efforts to determine the User story size. There may be some practical reasons which invite the changes. it is essential that User stories have the complete details and that backlog grooming is regularly practiced to uncover any hidden details. Initially it is difficult to determine the size. 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. Introducing work scope changes in the middle of the Sprint This is a very common mistake which can be disruptive for the team. The use of the ‘caparison’ method is recommended for determining the size of the User story. They then refrain from completing its details. Incomplete User stories and lack of Backlog grooming Defining User stories with complete details is the factor of time and intention. Scrum provides a platform to compare two User stories and determine the team’s efficiency in implementing them. 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. To avoid any potential confusion for the Scrum team. This practice not only varies the size of the User story based on the team’s efficiency. 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. Product owners sometimes believe that the work for a particular User story is so intuitive that no additional details are required.10 Mistakes to avoid in Scrum 10 Mistakes to avoid 1. Sometimes. but also makes it more difficult to determine the change in the team’s productivity with time. but these can 3 .

5. 4. But. First of all. but defeats the purpose of Scrum to deliver the ‘potentially shippable’ product. these exceptions should be avoided or minimized in order to provide better predictability and visibility. sometimes. it is very important to define the meaning of ‘Done’ for the team. 4 . Moreover. Shuffling team members in the middle of the Sprint Organization dynamics make changes inevitable. The recommended formats for Daily Scrum. It can be the result of poor or no backlog grooming. Sprint Retrospective and Sprint Review are defined to make the maximum use of the time and avoid any other potential requirements for unnecessary meetings. product owners can cancel the current Sprint and start a new one with updated Sprint goals. product owners hold the right to accept or reject the work. should be complied with ‘Done’ by the end of the Sprint. If the changes are unavoidable. 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. Any User story.10 Mistakes to avoid in Scrum impact the planned commitments for the Sprint. This can result in reducing the productive time available to the team. If there are any exceptions. All team members for a particular Sprint should be locked down and changes avoided in the middle of the Sprint. It is therefore suggested that the Scrum ceremonies be followed in their prescribed format in order to gain the most benefits. They can also sometimes demoralize team members. Sprint Planning. they can cancel the current Sprint and start a new one with an updated Sprint goal. certain ceremonies are missed in the Sprint. 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. The scope of the work should be locked down for a Sprint and any changes in the middle of the Sprint should be discouraged. planned for a particular Sprint. If product owners believe there are higher priority User stories. 6. Shuffling team members makes collaboration difficult within the team and causes confusion. but they can impact the planned deliverables for a Sprint if introduced in during its course.

they are so rigid about their roles that they do not want to cross their functional boundaries. but they all work to meet the Sprint goal. However. Playing by hierarchy of the team structure Scrum defines all team members as ‘Developers’ and recommends not having any titles. most of the organizations have a hierarchical structure and titles for employees. 8. which may result in a deviation from the Sprint goal. However. The Scrum Master should protect the team from any outside impacts. but they are at the same level in the Scrum team. Working without a Sprint goal 5 . ego clashes should be avoided. Any changes suggested by non-Scrum members should be first discussed with the Scrum Master and product owner. The Scrum team may consist of cross-functional team members. It may require them to wear different hats as the situation demands. All team members may be playing different roles. 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. It may drive team members to start tweaking actual hours to make them close to the estimated ones. For example. 10. Moreover. team members also get influenced by non-Scrum members as they report to them. They must understand that this provides them with the opportunity to examine the situation in retrospect and improve on the task estimation. sometime. It may result in the Scrum goal not being met. which means that team members should be groomed to play any required role as needed. This practice blurs the shortcomings and improvements required in task estimation. Therefore. 9. who can then communicate them to the team.10 Mistakes to avoid in Scrum 7. This hierarchical structure sometimes becomes a hindrance to collaboration. Team members should be groomed and prepared for the fact that the difference between estimated and actual task efforts can happen. Distinction of roles among cross-functional team members The Scrum team consists of cross-functional team members playing different roles. as they go along. some programmers say no to test the User story. But. they might experience the deviation between estimated and actual effort.

The second step was to introduce an internal service desk for the managers. Case Study The challenge We observed in one of the engagements that the Scrum team members were deviating from the hierarchy they reported to. and that the team provided a full transparent daily status. This allowed us to manage these request from outside the Scrum team. It was not only impacting the commitments for the Sprint. and convince them about the important of using the service desk to submit their requests. Solution offered The first step for Impetus was to negotiate and publish a working agreement between the Management and the Scrum Team. They were invited to Backlog grooming activities if they had a legitimate stake in the priorities. Managers were allowed to influence the priorities of the next Sprint by negotiating with the product owners. the product owner can actually reject the Sprint work. However. including department managers and upper managers. The Scrum goal should be stated in terms of recognizable (usually.10 Mistakes to avoid in Scrum The Sprint goal is the outcome of a Sprint planning meeting and defines the objective for the Sprint work. This was occasionally going against the goal of the Sprint. some teams overlook the concept of the Sprint goal and do not define it for the Sprints. working software) outcomes. it is difficult to weigh the success or failure of the Sprint. 6 . The most important task was to ensure that managers did not meddle with the priorities within the Sprint. Without this. If the goal is not met at the end of the Sprint. but also demoralizing team members. 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. It was causing confusion among team members regarding the expectations and priority of their tasks.

in whole or in part. 7 . Performance Engineering. innovative business models. transmitted. Cloud Computing. Altering these rules may provide short-term gains.INDIA: • New Delhi • Bangalore • Indore • Hyderabad Visit: www. Impetus Technologies. Mobility Solutions. we partner with our client base comprising large scale ISVs and technology innovators to deliver cutting-edge software products. USA Tel: 408. 5300 Stevens Creek Boulevard. No part of this document. CA 95129.213. Test Engineering.com Regional Development Centers . except as otherwise indicated.10 Mistakes to avoid in Scrum Summary The Scrum practice has defined the rules for Scrum teams to follow and allowed them to choose their own operational strategies. but may result in disadvantages in the longer run. stored. and an agile approach.3310 | Email: inquiry@impetus. About Impetus Impetus Technologies offers Product Engineering and Technology R&D services for software product development. Suite 450. With ongoing investments in research and application of emerging technology areas. may be reproduced. Inc. or used for design purposes without the prior written permission of Impetus Technologies Inc. SaaS.com Disclaimers The information contained in this document is the proprietary and exclusive property of Impetus Technologies Inc. Our expertise spans the domains of Big Data. San Jose. Following prescribed Scrum rules makes things more efficient and disciplined.impetus. and Social Media among others.

Sign up to vote on this title
UsefulNot useful