Debunking Popular Myths of Scrum Methodology

Scrum is a widely used framework that helps collaborative creation of software products — while addressing complex adaptive problems that come during product development.

However, there are several misconceptions about Scrum that fly in the face of developers, executives and the management. Some myths mirror from people’s fears while others reflect from their hopes.

In this post, we have tried to bust the some popular Scrum myths that prevent people from using Scrum effectively.

1. Presence of the Scrum Master is Mandatory in the Daily Scrum

A daily Scrum is an ‘inspect and adapt’ event. It scrutinizes the current state of the Solution to reflect on and identify improvements.  It also allows for the development team to manage the workflow efficiently.

The responsibility of the Scrum Master is to ensure that the daily scrum meeting takes place – and he/she may or may not choose to attend it — but it is not mandatory. The objective of the Daily Scrum is to provide an ideal environment for the development team to frequently communicate with one other and deal with issues as they arise.

 

2. The Sprint Backlog Remains Unchanged During the Sprint

The Sprint Backlog contains the list of work that development  team needs to complete in order to achieve the Sprint Goal. Though the Sprint Goal is fixed, the Sprint Backlog is not.

During the development process, the development team might discover one of the features doesn’t work as expected and might require some changes.

The development team makes changes to the Sprint backlog when necessary. It also helps the development team to inspect and adapt to reach Sprint goals.

 

3. New Releases Can be only Done at the End of the Sprint

The primary aim of the Scrum methodology is to give the development team enough time to convert the items in the Product backlog into done-items.

The term “Done” can have different meaning like code writing has been completed or the done items are at some higher levels of production stages.

The value of incremental work can be enhanced with user feedback. There is nothing in the Scrum framework that prevents releases before the end of the Sprint as long as product owner agrees to it.

 

4. The Product Backlog needs to have User Stories

The Product Backlog contains all functions, features, enhancements, requirements, and fixes that include changes which need to be incorporated into the product in future releases.

In simple words, it lists everything important that needs to be done. How the development teams achieve this is completely up to them. They create user stories, write use cases, mention keywords, or draw sketches.

The scrum framework focuses on what needs to be done but does not enforce any conditions or rules on how it should be done.

 

 

5. Priorities are Already Set in the Product Backlog

The Product Backlog is only a list of things that need to be done and the order of the things has nothing to do with priority. Scrum is always changing and evolving. The order of the Product Backlog is influenced by several things such as – dependencies, building codes, availability of third parties, costs, business conditions, and risks.

According to the Scrum Guide, “setting priority for things without considering other factors does not always maximize value”.

 

 6. The Product Owner Acts on Behalf of Stakeholders

Scrum allows for a collaborative discovery model. The product owner is the only person who talks with the Scrum team. Acting as a facilitator, the product owner may invite stakeholders for Sprint Review where their inputs might be gathered.

Also, he/she may create opportunities and platforms where the stakeholders may work with development team to clarify their assumptions and get clarity through testing.

7. Scrum Master should Resolve Every Problem

The project may have several impediments and the role of the Scrum Master varies as per conditions. Good masters help development teams to resolve their problems on their own.

If the team is finding difficulty in solving a technical problem, the Scrum Master can facilitate a session where large work is broken into chunks to find solutions to problems in a faster way.

 

8.The Scrum Master is Actually a Junior Agile Coach

The Scrum Guide clearly outlines the services of Scrum Master includes creating a self-organized development team and coaching them in cross-functionality. The responsibilities of an Agile Coach are far more expansive; as he/she tends to look at large organizational issues.

 

9. Story Points are Needed in Scrum

The story points technique is largely based on estimation. The primary objective of estimates in Scrum is to get a rough idea of how much work can be pulled in a Sprint.

Though the development team is committed to complete the estimated work in a given Sprint, there is no guarantee it would. This is because unexpected problems and better insights are likely to arise. Thus the whole idea of Scrum is to capitalize on change rather than control things based on estimation.

 

10. There is No Planning in Scrum

Scrum includes lots of planning such as Daily Scrum, Sprint planning, Sprint review, and Sprint retrospective. All these events are focused on planning things based on outcomes and new insights. The team always works as per the plan and adapt to the changes that come across while progressing towards completion.

 

Conclusion

In this post, we have busted common myths surrounding Scrum. The information given helps in better understanding of the Scrum framework and how to utilize it effectively in project management.

Leave a Reply

Your email address will not be published.

You may use these <abbr title="HyperText Markup Language">HTML</abbr> tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*