Get certified - Transform your world of work today


When Scrum Becomes Stale

3 May 2016

Scrum seems to be a bit like bread: When it is fresh, it is very tasty, and everybody likes a slice of it. But after a few sprints doing the same routines for planning, dailies, reviews, and retrospectives, Scrum may turn stale.

The sprint planning meetings deteriorate into task-assignment sessions, the dailies turn into status reports, the products are not always demonstrable anymore, and therefore the sprint reviews are used to rewrite the stories as a way to convert the unfinished work into new stories. And the retrospectives? If they are not abandoned altogether, sprint after sprint the same issues are voiced, most likely outside the power of the team to resolve them.

If a team does not watch out for signs of Scrum going stale, its performance will suffer. Its development will stagnate or, even worse, go into a downward spiral. What can a team do to avoid this? Are there early warning signs indicating that the team may not be on its way to top performance? From my experience with many Scrum teams, I have found recurring indicators that a team is not reaching its full potential and will soon be lagging behind.

Repeated, unresolved issues in retrospectives

Probably the clearest indicator of a team falling behind? Retrospectives that raise the same issues repeatedly. If the voiced impediments cannot be removed, the team will not improve. Good retrospectives are actually quite hard, but once the team starts getting used to them, it will become easier, and even fun, to think of new ways to improve.

Remedy: The team selects only one task and commits to resolving this issue during the next sprint. They also track it during and at the end of the sprint. To continue improving, this issue needs to be the highest priority for the upcoming sprint; otherwise, it will be down-prioritized sprint after sprint.

Stories are not demonstrable

Some teams have a hard time holding a live demo of all the stories in the sprint review. "There is no user interface," "This is only a technical story," or "The story was only to write a concept" are only a few of the excuses.

I observe this pattern mainly in companies with a strong Waterfall project management culture. The project manager splits the project scope into work packages (incorrectly called stories) that are assigned to team members according to skill or availability.

Keeping a strict focus on the business value, the team can always demonstrate each story to the customer. The story is completed (done, really done, no further work needed), and the system meets the quality level that means it can go into production if the product owner wishes.

Remedy: The team decides during the sprint planning how the story will be demonstrated. When a demonstration seems to be difficult, it is likely that the story is not small enough or not split in the best way to ensure maximum business value. So the team needs to split the story into smaller, demonstrable pieces, or change the story altogether so that the focus is on business value.

Unfinished stories are split and carried over to the next sprint

It's possible that a story is not finished by the end of a sprint. Then the whole story counts as not finished and is moved over to the next sprint, counting 0 story points for this sprint.

To avoid this, a team may opt to split the story into finished tasks (and counting them somehow), and unfinished tasks that get wrapped into a new story are to be completed in the next sprint.

Remedy: During the retrospective, the team discusses what can be changed so that delivering all stories in a sprint becomes the norm. Depending on the cause, one measure is to split the stories into small, deliverable pieces during sprint planning. Another may be to further remove impediments that hinder the team from delivering.

During sprint planning, tasks are assigned to team members

If you are not collaborating as one team, learning to do so is difficult. The traditional way to work on projects is to have a task assigned and solve it more or less alone. Less experienced teams often develop the pattern that they (or the ScrumMaster) assign the stories and tasks during sprint planning. Then everybody can work independently on his or her story and have full responsibility for it.

Unfortunately, this reduces overall team performance since the team cannot become more than its individual parts. Collaboration does not take place, team members cannot benefit from their collective knowledge, and improvement is difficult.

Remedy: During sprint planning, do not assign stories or tasks. Rather, let the team pull the most important task that is open during the daily stand-up. As a team, work on finishing the most important story first. Then start with the next-highest priority story. This way, the number of finished stories gets maximized, the team really collaborates, and each team member learns from others. The whole team is responsible for finishing all stories, not the individual who finishes only his or her stories.

Team members are not 100% on the project or are withdrawn from the project

I see this all the time: After a few weeks into the project, team members get pulled from the project (or were assigned to the project on a part-time basis from the beginning). The message is very clear: There are other projects that are more important, even if management tells you, "But they are still available for 20%."

Reducing team members' availability will hurt team performance and predictability. Even more, a person who is available for only 20% is often reducing another team member's performance so that the net benefit is worth less than if that person were not available at all.

Remedy: Don't. As a team, if a team member gets pulled away part of the time, think about excluding him or her altogether. Make it clear that you want only fully committed team members.

I am sure that there are many more patterns of Scrum teams losing their focus, discipline, and thereby their performance. Here I wanted to focus on the ones I consider the most important indicators.

But please let me learn from your experience. What are your strategies to make sure your team keeps increasing their performance?

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.8 (6 ratings)


Alex DiPasquale, CSM, 5/3/2016 6:54:55 PM
Great article Peter!
Michael Kuesters, CSP,CSD,CSM,CSPO, 5/6/2016 9:16:28 AM
Behind all this is a meta question.
People's actions are the consequences of the culture in which they operate.
The culture, in turn, is the consequence of structures and behaviours.

If you want the team to improve, you must be able to ask and answer, "Why are we doing that?", "Why are we observing this problem". As primitive as it may be, the 5-Why-Analysis is a great way of approaching this.

For example, when team members do not have demonstrable stories at sprint end, the problem may be a culture where that is acceptable. Maybe stakeholders can't touch the "Done" product? Why? Maybe they aren't even there? Why? Maybe they weren't even invited? Why? ...

It's easy to say "Let's plan for demonstrability" and fix that. It's significantly harder to say "Let's create a culture where a demo matters and developers are excited to actually have users touch the product in Review.", then the team will automatically find ways to make it demo-able.

Scrum reveals problems the organization already has. It does not solve them for you. But, careful: It only shows problems, not root causes.
It's your responsibility as Scrum team to discover these!
Srividya Natarajan, CSM, 5/8/2016 9:10:21 AM
Nice article

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up