Scrum myths

By Barnaby Golden, 27 February, 2015


The following are some common Scrum myths.


Velocity is a measure of performance

Isn't a higher velocity a sign of a more productive team?

The Scrum guide is very clear that velocity is purely about establishing the likely capacity of a team for future sprints. The actual value is irrelevant, it is the predictability that is important.


If you compare teams, isn't the one with the higher velocity performing better?

Comparing velocity between teams is meaningless. Each team will size stories in a different way. They may also have a different definition of done and different sprint lengths.


Should velocity be used to report to management?

Velocity is a metric intended to be used internally within the team to help them to put the appropriate amount of work in to future sprints. They may also use the velocity as a part of release planning, using it as a guide to would could potentially be achieved. Outside of the team, velocity has little meaning. Don't forget that story points are an arbitrary size as they are used as a measurement of relative and not absolute size. If a team wanted to increase their velocity all they would need to do is to increase their arbitrary sizing.


The Scrum Master is a kind of Project Manager

Is the Scrum Master accountable for meeting deadlines and budgets?

The Scrum Master is a facilitator that helps the team to work effectively. They are responsible for ensuring that Scrum is being followed and they also work with the team to overcome impediments. The Scrum Master has no greater authority than members of the development team. As such, they have no additional accountability beyond that which is defined by the Scrum Master role.


Is the Scrum Master in command of the development team?

The Scrum guide is very clear that the Scrum Master is a facilitator and not a manager. They have no authority over team members and should not be giving any orders. The Scrum Master works by advising and by coaching. They identify issues and work in a collaborative fashion to overcome them.


Should the Scrum Master be reporting to management?

Scrum is designed to be a transparent approach. The task board is used as an information radiator during sprints. At the end of sprints the showcase will demonstrate real progress - stories that have met the definition of done for the team. There should be no need for additional reporting from the Scrum Master or any other member of the team. If additional reporting is found to be necessary this indicates that the implicit transparency of Scrum is not being achieved.


There is no documentation in agile

Does an agile team produce no documentation?

Agile recognises that working software is preferable to comprehensive documentation. But neither the agile approach nor the agile frameworks stop the team from writing documentation. The intention is to only produce documentation that is going to be used and to not produce documentation just to follow a process.


If the code is self-documenting, do we need any other documentation?

The team should produce the documentation that is needed for the product to work well and for the team to be productive when doing future enhancement work. If self-documenting code achieves this then there is no need for other documentation.


There is no long-term planning in Scrum

When you are using Scrum, can you produce a long-term plan?

In agile we recognise that the further ahead we plan, the less accurate the plans will be. The best way to overcome this inaccuracy is to complete stories. The more stories that are completed, the less that are remaining and the more accurate the estimates will be.


What do we do if we need to know what will be in the next release?

When we want to know what will be in the next release we do release planning. This involves exploring all that will be required to achieve the desired release. The team's velocity can be used as an indication of what could potentially be achieved. Once work has been started the release plan will be continually updated to reflect actual progress. In this way, the closer we get to the release the more accurate our forecasts will be.