10 Common Scrum Mistakes and How to Avoid

28 / Sep / 2017 by Nidhi Choudhary 0 comments

More and more product companies are making a shift from their traditional way of working by embracing new-age digital technologies. This is mainly because they want to remain competitive and reach out to market faster than their competitors.

While adapting to digital technologies, these companies are also leveraging Agile methods and processes for a disciplined project management practice. Agile encourages frequent feedback, iterative development, teamwork, rapid and frequent delivery with a high-quality build and much more.

According to “11th annual State of Agile Report” produced by Versionone, below are the top reasons for a product owner to use Agile.


There are various Agile frameworks that product companies use such as Scrum, XP and Kanban. In this blog, we will walk you through Scrum and top 10 mistakes that product owners or project managers should refrain from doing while practicing Scrum.

What is Scrum?

Scrum is a process framework which is being used by organizations who are seeking to improve their complex development practices. Apart from clarifying the relative efficacy of the product management, Scrum provides some of the robust features to bring transparency in the process.

Here are some of the salient features of scrum

  • Activities are time boxed.
  • Capability to adapt itself to changing market conditions.
  • Scrum team is self-organized
  • Lightweight framework
  • Faster development
  • Iterative and incremental approach for controlling risk

Though Scrum is simple and easy to understand concept, when it comes to implementing this framework, it can be difficult.

Outlined below are 10 common Scrum mistakes and tips to avoid them

1. No Retrospective

The retrospective is one of the prominent practices and a core component in Agile development as it helps to assess a project. Not having a retrospective can derail the project. Having retrospective at a regular interval increases team’s efficiency. Teams can make detailed notes on work accomplished, pending tasks and the way or working to enable continuous development.  Without an effective retrospective, finding the gaps can become a complex task.Retrospective can be structured in 5 steps:

  • Setting of  the stage
  • Data Gathering
  • Generating insights
  • Decide what all to do
  • Closing of the retrospective

 The overall goal of retrospectives at the end of every sprint is to help the team to improve their way of working.

 Here are some of the benefits of doing Retrospective at the end of every sprint:

  • Give freedom to team members to share their view in a more effective way.
  • It helps the team to become Agile and lean.
  • With effective implementation of retrospective meetings, teams can improve their development process.
  • It is a way of getting feedback on what all is to be.

 Following are some interesting Agile Retrospective ideas 

  • Kudos cards: This technique is used to reward the team members.
  • Lego retrospective: In this technique, team members are able to express their thoughts in a much playful way.
  • High-Performance tree: This technique can be a great way to help the team in defining the vision for themselves which will help them to improve their overall performance.
  • Sailboat: This technique helps the team member to know their vision and moreover it helps them to know the risk that is involved in the path. Also, introduce them to ways that can help them achieve their objectives.
  • Happiness index: This is done to know the emotions of team members during the sprints.This technique is suitable for any type of team.   

2. Lax Daily Stand-ups

Among various Agile software development techniques, daily standups are becoming a ritual for the teams. Daily stand-up plays a very crucial role for better communication and effective collaboration among team members. A daily face to face meeting for 15 minutes will bring more transparency and visibility into the given project.

In order to avoid extending the conversations keep it simple and make sure the following questions are being addressed:

  • What has been accomplished by far
  • What obstacles are been faced
  • What all is to be accomplished in future.

Internally the stand-up can be done in order to discuss the issues and challenges. Daily stand-ups can also happen in a distributed mode. Scrum master along with other members should do this in an ongoing way.


Daily stand-ups are a tool to regularly synchronize so that teams can have following advantages:

Quick considerations for daily standups:

  • Don’t take daily standup as a status meeting
  • Don’t forget to include the 3 basic question
  • What all activities accomplished by far
  • What is to done in present
  • What were the obstacles the team faced
  • Don’t use the daily scrum for discussing technical problems
  • Don’t use the meeting for planning purposes
  • Daily scrum is not meant solely for the scrum master

3. Practical without principles

Agile principles act as a backbone to all the frameworks. At times, teams follow Scrum practices but still fail to instill Agility because they miss implementing Agile principles.

Agile is based on 4 core values:

  • Individuals and Interactions Over Processes and Tools
  • Working Software Over Comprehensive Documentation
  • Customer Collaboration Over Contract Negotiation
  • Responding to Change Over Following a Plan

Principles are like visions and practices are like the features.

Principles talk about tasks to be accomplished where practices talk about the ways of accomplishing such tasks.

4. Scrum master is a project manager

In Agile, there is an assumption made related to Scrum master and project master that both of them have the same role to play. However, this is not the case here.

Scrum master and project manager differ in terms of their roles. The role of Scrum master is well defined whereas the role of project manager keeps evolving basis the project needs.

Let us have a quick glance at  3 major roles in Scrum:


Product owner 

  • Creating product backlog which is based on the product vision.
  • Defining user stories which are important and have high business values in the product backlog.
  • Monitoring activities in the project.
  • Ensuring a proper maintenance of product backlog.
  • Providing access to backlog to other team members.
  • Ensuring product backlog item is appropriately stated and the same is well defined in the backlog.
  • Having a clear sprint goal even before a sprint is initiated.


Hats off to the Scrum master

In Agile product development, scrum master plays a crucial role. Some of his responsibilities are outlined below:


  • Facilitating Scrum ceremonies.
  • Encouraging face to face communication among the team members.
  • Ensuring that impediments are raised on time and are eliminated on time.
  • Facilitating the release planning.
  • Planning sprints
  • Guiding and protecting a team from external obstacles.
  • Empowering team to refine its practices as needed and keeps on improving.
  • Ensuring that all the artifacts are in place.
  • Enabling cross-functional collaboration

 The Development team

The development team is a cross-functional group and is cohesive in nature. The team members are highly self-organized taking care of the Sprint backlog by themselves. They also have the authority to use tools and technologies required to accomplish the project.

5. Not raising obstacles early enough

Scrum is known for addressing obstacles faced by the team early so that the delivery of the product is not hampered. In Agile, these obstacles are called impediment backlogs. However, Scrum master should not centralize solving obstacles to himself but also involve teams were required so that teams can themselves resolve impediments where possible. This will thereby enhance the overall capabilities of the team to handle more and more impediments in the future without the Scrum master.

Displaying these roadblocks on a whiteboard and revisiting them in standups is a good way to resolve them quickly.


6. Product backlog not ready

In a Scrum project, while planning, team members prefer to keep a track of activities by creating a list. The list is a way to remember what all tasks are required to accomplish, what is the estimated time to accomplish the tasks and what all is being accomplished so far in the project. The list is called as a product backlog.

Although this is similar to ToDos, product backlog differs in follow ways:

  • Every entry in the list will add value for the customer.
  • The position of the entries defines the level of details required on the list.
  • The entries are prioritized and ordered accordingly.
  • Scrum product backlog is a short description of all the functionalities required for the product.

Scrum Product Backlog needs to be maintained for sustainability of the process which comprises the following steps:

  • As new items are added to the list, existing items are changed or removed
  • The most important item is moved to the top of the list and treated as a priority
  • Re-estimate the entries in Product backlog

A proper maintenance of Scrum product backlog will not only create buy-in from the Scrum team but also provide a clear picture of the requirements. Missing on Scrum product backlog can derail the development, delay launch or fail the product post-launch.

7. Less  focus on tools

Leveraging on the latest tools can benefit in multiple ways such as

  • Estimating and creating user stories.
  • Maintaining product backlogs.
  • Helping with designing and defining of future sprints.
  • Visualizing team activities on a single platform.
  • Creating project status.

Below outlined are some tools that can be taken into consideration:

  • Scrumwise
  • Agile tracking tool
  • Agilo for Scrum
  • Airgile
  • Daily-Scrum
  • EasyBacklog
  • Agile Express
  • Mingle

8. Lack of product owner’s involvement

The role of a product owner is very time-consuming. We have listed down some responsibilities that product owner needs to perform:

  • Effective collaboration within the team.
  • Prioritize the backlog for the team.
  • Ensure daily scrums and sprint reviews.
  • Bridge the gap between the team and the top level authority.
  • Ensure that everybody adheres to a single vision.

A product owner can not afford to avoid participating as his contribution and involvement will steer the project.

9. Communicating through Scrum Master

Communicating through scrum master could be a good option but for teams that are working in the same place, it is better to communicate problems or goals personally. Looping in scrum master where the information can be obtained directly increases the time and delays project delivery. Moreover, some information can directly be obtained from the concerned team member or product owner.

10. Product owner centralizes solutions

Scrum is based on the rugby approach by Nonaka and Takeuchi, where the team is self-organized and versatile. The very first thing a product manager needs to take into consideration is giving freedom to his team to come up with the alternate solution to a challenge in the product backlog. This makes the team more flexible and enables collaboration. As per the Scrum guidelines, the product owner is not only responsible for maximizing the overall value of the product but also ensuring the development of the team.

Second most important thing is that imposing decisions without adapting to market changes will lead to product failure. He should consider every release as a growth opportunity for the product, organization and team.


Scrum has been one of the longest standing and promising frameworks of Agile (read it since the 1990s). While more and more companies want to build products and launch them faster to market, practicing Agile in a correct way is important. A scrum master or product owner will not be able to successfully launch the product if the team doesn’t adhere to best practices. Product companies that are looking at outsourced software development should also ensure that their outsourcing partner is following the best practices and avoiding these Scrum mistakes.


Leave a Reply

Your email address will not be published. Required fields are marked *