A Big Ask

You are the Scrum Master of a six-person development team at a growing software company known for delivering custom applications on tight timelines. Over the past few months, you’ve noticed a growing problem: your team’s workload has ballooned out of control, and instead of focusing on sustainable work practices, they’ve been turning to leadership, requesting more time to finish projects rather than negotiating for more manageable workloads.

This trend has led to a vicious cycle. Each sprint starts with the team committing to a large amount of work, under pressure from leadership to meet backlogged deadlines. But the increased volume of tasks leaves the team with little time to properly plan or analyze what needs to be done upfront. Consequently, they end up diving into development unprepared. Predictably, this rush leads to technical debt, errors, and missed deadlines—causing further delays. Leadership is unhappy with the delivery timelines, and your team is becoming increasingly frustrated.

The current sprint is no different. The team has again overcommitted, taking on too many user stories without adequate planning. There’s a sense of burnout, and morale is low. The quality of their work is slipping, and leadership is expressing dissatisfaction with the pace of delivery. The tension is palpable in your daily standups, where team members have started to voice concerns about the unsustainable workload.

It’s Friday afternoon, and you’ve just finished a difficult Sprint Retrospective. During the meeting, several team members expressed their frustrations:

• Michael, the senior Developer, complained, "We’re barely doing any analysis anymore. We jump into coding without understanding the problem, and that’s why everything keeps getting delayed. I can’t remember the last time we delivered something without bugs."

• Sarah, the Product Owner, noted that leadership is increasingly impatient with the team’s performance. "I’ve been pressured by management to push more work into each sprint. They think we’re moving too slowly, and it’s making me nervous. I don’t know how to push back effectively."

• Andy, a junior Developer, said, "I’m having a hard time keeping up. Every time I start on a task, it feels like we’re missing details. By the time I ask for clarity, we’ve already wasted time, and then it’s a rush to catch up."

The team is feeling stretched thin, and the backlog keeps growing. Yet, the real issue is apparent: the lack of upfront analysis and design is hurting the team's ability to deliver quality work on time. But with deadlines looming and leadership applying pressure, it feels like there’s no room to pause and course-correct.

Later that day, you have a scheduled meeting with Emily, the VP of Product, who oversees several teams, including yours. She’s frustrated. "We need to get these projects done, and it feels like your team is falling behind, week after week. I understand there are challenges, but you’re the Scrum Master. Isn’t it your job to help the team manage their time better?"

She leans in. "I can’t keep going to the CEO and telling him we need more time. We need results. Maybe we need to push them harder—get more work into the sprints. Everyone else is pulling their weight. Is it a training issue? Do we need to bring in more people?"

Her expectations are clear: more work, faster.

At the same time, you are aware that the problem is deeper than just "working harder." The lack of upfront design and analysis is causing the team to rush into implementation, and the resulting rework is delaying the projects even more. But taking time upfront to plan seems impossible with the current sprint structure. Moreover, the team’s process of sizing stories has become inaccurate—they often underestimate how much time is needed, leading to overcommitment.

You also know that the team is starting to burn out. They’re putting in longer hours, working weekends, and becoming more disengaged. The pressure from leadership is making it harder to push back against the amount of work being pushed into each sprint.

Now, as the Scrum Master, you are at a crossroads. You must decide how to reset this process, manage expectations, and improve the team’s performance while maintaining morale. Several options present themselves, but none seem straightforward, and each comes with its own risks and potential benefits.

1. You could sit down with Emily and Sarah to explain that the team needs to take on less work per sprint to allow for more thorough upfront analysis and design. You would argue that delivering fewer, well-thought-out features will ultimately be faster and more efficient than continuing to take on too much work and having to fix errors later. This could reduce the pressure on the team, giving them space to plan and deliver higher-quality work. It would help to rebuild morale and prevent burnout. However, leadership might see this as resistance and could push back even harder. It could damage your credibility, and you might be blamed if deadlines are missed even further.
2. You could propose a sprint dedicated solely to planning and design?—?effectively creating a “Sprint Zero.” This would give the team the time they need to analyze and design upcoming features properly without the pressure of immediate delivery. The team would have a clear runway to plan and build a foundation for success. It would improve the quality of future sprints and prevent rushed work. However, leadership might see this as a delay tactic, and it would delay any new feature development by a sprint, which could frustrate management further.
3. Another option would be to go to leadership and request additional people, such as hiring more Developers or outsourcing certain tasks. This could alleviate the team’s workload and help them keep up with the project backlog. That might relieve the pressure without slowing down current work, allowing the team to meet deadlines without burning out. However, onboarding new team members or outsourcing could create its own delays. The team might still feel rushed, and you might not address the root cause (lack of upfront planning and overcommitment).
4. You could overhaul the sprint process by introducing more strict story sizing and prioritization rules. This would involve reducing the scope of each sprint and ensuring that stories include thorough analysis and design components. This could bring much-needed structure to the team’s work, reducing overcommitment and ensuring that tasks are better thought out before development starts. However, this could be a hard sell to both the team and leadership, as it would slow down the perceived pace of delivery. The team might struggle to adjust to a stricter process after being in “crunch mode” for so long.

The team needs a reset?—?but how you approach this reset will have significant consequences. The pressure from leadership is mounting, the team is burning out, and deadlines are looming.

What is your decision?

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.