The Top 20 Scrum Myths - Busted!

I love a good scrum myth don't you? But I'm constantly amazed at how many people are actually still doing them so I've compiled my favourite top 20. I'll tell you what they are and what you should be doing instead. How many of them are you still doing let's find out.

No.1 Story points & Velocity

In at number one, it had to be didn't it? Story points and velocity. You might be surprised to learn that story points and velocity have never been part of scrum or the scrum guide. In fact back in 2019 Ron Jeffries who created story points apologised for it on X formerly Twitter in fact he also called the whole idea of estimation evil.

Now Ron Jeffries, if you didn't already know, is a co-creator of eXtreme Programming and one of the 17 who created the Manifesto for Agile Software Development.

So what can you do instead? Well if you follow this blog you'll already know the answer, use flow metrics, cycle time and Monte Carlo Simulation.

No. 2 User Stories & Epics

And at number two, user stories and epics. Again these have never been part of Scrum or the Scrum Guide. As with story points they come from eXtreme Programming.

If you write in detail all the things you want to get done before you start the sprint you're missing the point. The sprint is where you as a team collaboratively work on the solution testing and confirming with the customer.

It's fine to have a few notes ahead of the sprint but these are reminders of conversations you need to have in order for you as a team to work on the solution with the customer.

No. 3 Estimates

In at number three, ooh now this one can really stir things up, I’ve found people can get very emotive about this. Now estimates are not mentioned in the Scrum Guide and as you've just heard have been called ‘evil’ by Ron Jeffries. But forecasts are mentioned in the Scrum Guide. The Scrum Guide says ‘in complex environments what will happen is unknown only what has already happened may be used for forward-looking decision- making’.

We live in a data driven world so use the data that is in your agile tool, being collected automatically. Calculate your cycle time and forecast with Monte Carlo simulation.

No. 4 ‘Ceremonies’

Number four, ceremonies, Scrum ceremonies - they sound a little bit sinister to me. They have not ever once been called ceremonies! In the Scrum Guide they are called Scrum ‘Events’ - meetings! So let's stop using language that creates some sort of mystique over the use of Scrum, it's a simple straightforward way of delivering value.

No. 5 The 3 Questions

Number five, the three questions. The dreaded three questions every morning. Well they were finally dropped from the Scrum Guide back in 2020 and good riddance.

I never found that they provided any value and turned the morning meeting into a status update. So what should you be discussing? Progress towards a Sprint Goal and does anything need to change.

No. 6 The Daily ‘Standup’

Number six the daily standup. What? It has never been called the daily standup! This is another hangover from eXtreme Programming. It's called the Daily Scrum. Semantics maybe. But in these hybrid working days who is really standing up when working from home, unless perhaps you're one of those people with those motorised standing desks.

But I have heard it called the daily sync or team sync which I actually quite like.

No. 7 Sprint Review is a ‘demo’

Number seven, the  Sprint Review is a ‘demo’. Oh dear, if you're treating the Sprint Review as a demo where you get sign off, that smells of many anti patterns. You should be constantly interacting with your Product Owner, stakeholders and customers throughout the Sprint showing them progress and bouncing ideas off them.

The Sprint Review is primarily a feedback gathering exercise to collect more ideas about what's been delivered which can then go into the backlog. It's also the place to discuss progress towards the Product Goal. It should be a working session not a PowerPoint presentation.

No. 8 Completing all work taken into Sprint

Number eight, completing all the work taken into sprint. Again this is yet another anti-pattern. The goal of the Sprint is the Sprint Goal. It doesn't matter if all the work taken into sprint is done or not the only thing that matters is the Sprint Goal.

It's one of the reasons why I just don't see any value in sprint burndowns, velocity or story points for that matter.

No. 9 Sprint Backlog can’t change during the Sprint

Number nine, the Sprint Backlog can't change during the Sprint. Well, since the goal of the Sprint is the Sprint Goal this is obviously yet another anti-pattern. Yes of course the Sprint Backlog can change during the sprint and it should if you're working closely with your stakeholders and customers shaping the solution together.

Look, if you try to write all the work items up front before starting the work what you're really doing is iterative waterfall.

No. 10 Scrum is only for Software Development

Number 10, Scrum is only for software development. Well this might have been true once but it hasn't been true for at least 10 years. Scrum can be used in multiple environments and situations.

I recently used Scrum for a client to improve their processes and efficiency and they didn’t have anything to do with software at all.

No. 11 Scrum Master HAS to be technical

Number 11, the Scrum Master has to be technical. Now this isn't true either, you can be completely non-technical especially if you're not working in software development.

However, you do need to understand the technologies and at least have an appreciation of how software is developed if you’re working in software development. So although it is true you don't need to be technical it helps if you have a good understanding.

I’d recommend reading ‘eXtreme Programming Explained’ by Kent Beck for an appreciation of the kind of issues presented in software development.

No. 12 Scrum Master must be present during the Daily Scrum

Number 12, the Scrum Master must be present during the Daily Scrum. Again not true, the goal is self-management. If the Scrum Master spoon feeds the team how will they achieve that?

The only thing the Scrum Master needs to do is make sure the Daily Scrum happens and that the team are getting value from it. In fact, it's good practice not to show up at a Daily Scrum from time to time to see if the team hold it and get value from it.

No. 13 Scrum Master removes all Impediments

Number 13, the Scrum Master removes all impediments. Not true, self management remember. The Scrum Master is responsible for helping the team remove their impediments by themselves or highlighting them if they're being missed.

No. 14 Releases are only done at the end of the Sprint

Number 14, releases are done only at the end of the sprint. Again not true. A release can be done at any time during the sprint, it could even be done every day or every hour!

The goal of the Sprint is to have a increment ready that fulfils the Sprint Goal but you don't even necessarily have to release it even at the the end of the Sprint.

No. 15 Scrum Master is a junior Agile Coach

Number 15, the Scrum Master is a junior Agile Coach. Now I know a lot of people think this but it's simply not true. The difference between a Scrum Master and Agile Coach is very little if they're both experienced and good at their job.

A point to note here is that the Scrum Master accountability not a junior position. If you work on that basis you're going to run into trouble. The Scrum Master is a leadership position. If you put a junior or inexperienced Scrum Master into a team how do you expect that team to become high performing or the Scrum Master to build any trust?

No. 16 There is no planning in Scrum

Number 16, there is no planning in Scrum. I would say there's just as much planning if not more planning in Scrum than waterfall.

You've got a Sprint Planning event every Sprint plus you’ve got the Daily Scrum which is yet another planning event where you have the chance to change the plan.

So to think there's no planning in Scrum is hogwash.

No. 17 Scrum is a Methodology

Number 17, Scrum is a methodology. I hear this one quite a lot as well. Scrum is a lightweight framework definitely not a methodology.

A framework is a skeletal structure around which solutions are built. A methodology is prescriptive and may also have specific deliverables such as documents for planning or assessment. They're also usually fairly stringent in how they do things and they are also less adaptive than frameworks.

And by the way, agile is also not a methodology either, it's a set of values and principles.

No. 18 Scrum is agile

Number 18, Scrum is agile. Well no, no it isn’t. Now it does come under the very broad umbrella of agile but just because you're doing Scrum doesn't mean you'll automatically be agile.

However if you're doing Scrum then in my opinion you shouldn't need to do too much more to be agile.

No. 19 Velocity and value are the same

Number 19, velocity and value are the same. Oh dear, oh dear, oh dear, oh dear! Well look, to start with velocity is a total waste of time and has absolutely nothing to do with value.

You can produce something each Sprint with slick working teams, always completing the Sprint Goal, but if you don't measure the actual value delivered to customers, listen to them and take account of their feedback, how would you ever know if any value has been delivered at all?!

No. 20 Scrum means no Documentation

Number 20, Scrum means no documentation. Ah well this is just not true at all. It just means only do the documentation that is needed. If you're going to produce something then make sure there's a valid reason for it and that it's kept updated. Code written should be self-documenting.

No. 21 Scrum Master is the teams admin!

And finally number 21, I know I said only 20 but this is a bonus one, the Scrum Master is the team's admin!. Well look, I see this a lot. The Scrum Master is not there to move the team's tickets around a Jira board or to write a status update after each Daily Scrum for management. Or just to schedule Scrum Events and facilitate them.

If this is all a Scrum Master is doing there's literally no point in having one at all.

Ok that's my top 20 well 21. If I’ve missed any of your favourites let me know in the comments below and we can have a chat and maybe a cheeky laugh about them.

Also, let me know if you're actually doing any of them, no judgments I promise, and let's see if I can help.