5 reasons why scrum sprints become disasters
1. No clear sprint goal
Setting a sprint objective (the key outcome of the sprint) is a must. However, sometimes the Product Owner and the team don’t decide on any particular tasks for the sprint and agree to the “let’s see how it goes” strategy.
As a result, the development team often works on tasks of a lesser priority or in the wrong order. It may lead to different features not working together and the team wasting time adjusting them.
Moreover, the clear goal of the sprint would motivate the team to work together to achieve it. On the other hand, when there is no explicit objective, everyone works on their own tasks, which is detrimental to teamwork.
Before the planning, the Product Owner should analyze the project scope and ensure the priorities of the stakeholders didn’t change. Then, according to the gathered information, he or she, together with the team, should create a sprint objective.
At the meeting, the PO should discuss the goal with the team, and let them create a plan that would bring them closer to achieving it.
2. Indecisive Product Owner
If the PO is indecisive or doesn’t think big-picture, there would be no authority for the team. PO not taking responsibility for the project equals a team with no leader. It puts the whole project at risk, as there is no plan to follow, and tasks are selected randomly, which may result in scope creep (see point no. 3).
Sometimes the team would take over the PO duties and assign the tasks themselves. As much as it might feel like a good alternative, it’s a double-edged sword. In this case, the team will be less focused on their actual work and might be less motivated to finish the job. They also don’t know the product this well and would make decisions from the technical, not business point of view.
Fortunately, many companies using the Scrum methodology hire a person responsible for solving those issues. Scrum Master should encourage the PO to organize additional calls with the clients to get to know the product better and do more research to understand the market needs. SM should also share some techniques to help PO communicate better with the stakeholders and teammates. It definitely is a long-term process and success of it depends on the PO’s approach.
3. Underestimating story points
Story points are the representation of the time needed to complete the task. Usually, teams would underestimate it because they don’t discuss the risks (such as technical aspects) enough.
For example, if the team realizes they have to build a given feature in a different technology, the initial time for completing the task may increase even three times. Moreover, it may result in scope creep, which is caring over the leftover tasks from the previous sprint into the current one.
Let’s look at an example:
The team didn’t meet the goal of the previous sprint. They haven’t closed the tasks:
- 1 x 2 story points, unfinished,
- 1 x 3 story points, unfinished,
- 1 x 5 story points, in progress,
- 1 x 8 story points, almost finished, in code review.
So they say: “Okay, let’s not count the 8-story points one, as it’s almost finished, and let’s not worry about the 5-story points one, as it’s only one day of work.”
They often forget that tests, code reviews, and edits would take additional time. If this trend continues, the team will end up with a huge pile of open tasks. They may even need a separate sprint to close them all.
During the retrospective, the Scrum Master, PO, and the rest of the team should discuss the tasks that weren’t delivered on time. Maybe a more detailed description would work better if they were too complex. Some teams like to break it into WHY, WHAT, and HOW sections or set the user story and acceptance criteria.
The other part of the solution is making the team and clients aware that more isn’t always better. Some stakeholders push the team to take as much work as possible for the sprint. They worry that once the team completes assigned tasks, they would say they’re done for the sprint. In my experience, this is far from the truth. The team wants to finish the project just as much as the stakeholders ;)
4. Rebellious team
Immature agile teams might not completely understand the need for all those meetings and additional responsibilities that come with Scrum. It may seem like a big waste of time.
Naturally, their first idea would be to reduce the number of meetings and shorten them.
But it never works well for the team as they don’t have enough time to discuss the iteration plan and technical aspects.
The rebellious team doesn’t engage in planning, stand-ups, or retrospective. It results in a bad sprint plan that is impossible to implement and would probably lead to scope creep.
Quite often, during the retrospective, the team realizes the problem and feels the need to solve it. They would come up with some suggestions, e.g., separate technical planning for the developers and QAs. During which they would look even closer at the use cases, test cases, and discuss the implementation of technical details. Some teams may want to create a physical timeline on the wall, divided into days.
With time the team matures and learns its influence on the project. Managers should be engaged in this process of growth, for example, by encouraging their team to step out of their comfort zone from time to time.
In this article, we wrote a few words on how to implement Scrum in your team. Make sure you check it out after this one.
5. Not adjusting the task and the scope
Adjusting a scope when needed is one of the main ideas behind Scrum. Flexibility allows choosing the best way to develop the product and guarantees the best quality in the shortest amount of time.
During the development, the team may encounter obstacles they did not expect. It may stop them from delivering everything that was planned for the sprint.
In such cases, the team, together with PO, should meet and decide which tasks can be dropped at the moment, and what have to be finished. Unfortunately, this is not always the case.
Once again, the Scrum Master would be the perfect person to intervene. He or she should make the team and the PO aware of the importance of the work prioritization and strategic scope adjustment.
A vast majority of problems listed in this article come from poor communication and teamwork and those are the areas you should work on to avoid those problems.
Scrum is about voicing your concerns, suggesting better ways of doing something, and working together. No matter what your role in the team is, you should remember these principles and apply them daily.