Scrum is known as a framework that ensures the important things to be done first. It is often introduced in companies where different approaches of prioritizing the next workable item did go wrong. Scrum is often seen as the savoir in this scenario as it should deliver the right stuff each sprint. But more than often the same mistakes about the prioritization of workable items are done in scrum the same way as it is done in other approaches. This article describes four antipatterns regarding the prioritization.
Multiple Priorities
In Scrum the sprint backlog is ordered in a sense that if the team completes the topmost sprint backlog items the value that will be delivered has been maximized. This means that each team member should focus on completing these top items.
If each team member does have a different priority to work on, they counteract against creating the maximal value. Hence if a dev is stuck on for example the first item in the sprint backlog and asking for help, answering that one is having other priorities it is not the valuable items that are done within the sprint but the personal priorities of the dev.
Naturally, the developers do not produce a priority on their own. Multiple priorities come from multiple sources of priority. It is not the sole priority of the sprint backlog that is taken into consideration but mostly the priorities are pushed into the team from somebody else, sometimes even the product owner. Any scrum team should speak out against multiple priorities as they reduce the chance of delivering the right things first.
Teams outside the scrum team
The development members of a scrum team might have more responsibilities than being a fulltime developer for the team. Developers may only be half of their time available to work on sprint backlog items and need to undergo other tasks in the rest of their time. This becomes a problem if the workload about these different responsibilities is not transparent for the team, as it if often the case, or team members are totally underestimating the effort for their side quests.
Team member might even be part of another team or taken into urgent task forces during a sprint. Having obligations in different teams at the same time and the urge to fulfil both obligations will lead to not being able to focus on any of the work that needs to be done.
Development tasks a team can handle should always be executed by the team itself and within the planned sprint. Do not take development members temporarily out of the team to do something that seems more important. Let the team handle it.
Additionally, any task outside of the scrum need to be transparent and preferably consistent over time. This makes sure the team does have a good understanding of their skills and their capacity for a sprint.
Disregard the sprint backlog order
Scrum master notice that developers are working on sprint backlog items that do not have top priority even if the workable items at the top have not been finished. As described in the first section having multiple various sources of priority could lead to not focus on the workable items at the top.
Sometimes it is even due to personal preferences, skills and sometimes even convenience. Scrum master need to take action against this. Make clear that the sprint backlog is the only source of priority. Therefore, the product owner needs to know about the external priorities of any item. This way, he even might consider the product backlog item as important enough too and accepts that the developer is working on these items. If this is not the case, you need need to convince people to work in the top items first. Scrum master can help developers as well as the company to understand the process of creating value.
Tasks in progress > Developer
Having more product backlog items in progress than you have developer within the scrum team is an unmistakable sign of not focusing on the most valuable items in your sprint backlog. This might have distinct reasons. Sometimes developer do need some more information about a feature they have started developing. Sometimes they need to wait for technical impediments to be solved. Sometimes it is also due to personal preferences, skills and convenience that developer tend to start working on a new product backlog item even if others have not been finished yet.
Take care that every sprint backlog item is clearly described and did not need any more information to be started. If information is needed anyway developers should actively try to get this information and should not wait that the information is somehow finding its way itself.
If developers are regularly waiting due to the same technical impediment this needs to be observed and removed in the future. Impediments that need to be removed from the team could be a good topic for a scrum retrospective. It provides the possibility to deeply talk about the root cause of the problem and find a solution for it.