How to Survive The Sprint

Dev Leader Weekly 104

Aug 02, 2025

TL; DR:

Raise awareness if sprint commitments are unreasonable
Work should not come at the cost of your mental health
Live stream will be Monday, August 4th at 7:00 PM Pacific on the Dev Leader Podcast YouTube channel!

👀 YouTube News 👀

Hey folks! I've been trying to get my other channels together so they can go live by the end of this week... And I've done it!

If you are interested in C#, dotnet, and programming tutorials:
https://youtube.com/@DevLeader

If you are interested in the resume reviews and interview guidance:
https://youtube.com/@DevLeaderPathToTech‬

If you are interested in the podcasts, general software engineering, and AMA livestreams:
https://youtube.com/@DevLeaderPodcast‬‬

If you enjoy Q&A vlogs where you can submit questions and get a video response:
https://youtube.com/@CodeCommute‬‬
https://youtube.com/@CodeCommuteClips‬‬

My main channel will remain C#, dotnet, and programming tutorial-focused -- that's my promise. I have a BUNCH of videos I want to record, but I am just trying to get all of this organized. I appreciate your patience!

p.s. - Please only consider subscribing to the other channels if you like that kind of content. The whole reason I am doing this is because I am trying to get my videos in front of the right audience 😃

Surviving Sprint Pressure Without Losing Your Growth

As a junior developer, sprint pressure can feel relentless.

One minute you're celebrating your first pull request getting merged. The next? You're staring down sprint deadlines, blocked on problems you don't fully understand, wondering if you're about to get fired.

If you've ever felt this way, you're not alone. This article is based on a video response I made for someone who had this exact fear:

I've coached and managed engineers who hit this wall again and again--where team processes, lack of mentorship, and silence around struggles create a recipe for burnout, disengagement, and fear.

But here's the good news: even when you feel stuck in a system you can't control, there are ways to navigate it and grow.

Let’s talk through how.

The Sprint Commitment Trap

You’re asked to commit to a chunk of work every two weeks. That’s normal. Well, "normal" as in not that unusual if you're following some type of sprint model.

But here’s where it falls apart:

You don’t fully understand the ask
You hit unexpected blockers
Nobody pairs or reviews early
Every sprint seems like there's more
And your Scrum Master just wants the sprint green on Jira

Suddenly, you’re skipping tests. Shipping half-baked code. Praying no one notices.

That’s not engineering. That’s survival. And that's exactly how the person felt when they were asking about what to do when their scrum master keeps demanding impossible sprint commitments.

It’s not sustainable.

Actionable Tip: Start reframing sprint planning as a negotiation, not an order. If something seems risky or unclear, speak up:

"I’m not sure I understand the scope yet--can we split this into a spike or break it into smaller deliverables?"

Even if it’s not welcomed immediately, this sets the tone: You think critically about commitments.

"I’m not sure that this amount of scope is achievable within the next two weeks. Can we discuss the lower end of the priorities further?"

Again, this needs to be vocalized if it's truly not feeling achievable. A bit of a stretch is fine, but if it's constantly feeling impossible -- let it be known!

Healthy Conflict Is Good (Seriously)

In my opinion, great engineering teams thrive on healthy conflict:

Product wants more delivered
Engineering pushes back with technical realities
Together, they find the right trade-offs

Some people hate this idea. I've heard people say that it shouldn't feel like an opposition, but it should feel like a team.

But I DO agree with that. Both sides want what's best for the customer, but they may have a different perspective on how to achieve it. It doesn't mean it should always feel like a battle, but having different perspectives on how prioritization works is a great way to get people on the same page.

When there’s no pushback, you either:

Ship garbage under pressure
Burn people out
Or both

Actionable Tip: Learn phrases that keep things collaborative:

"That seems like a tight fit--if we include X, what would you suggest we drop to make room for it?"
"We could try, but quality might take a hit. Is that an acceptable trade-off this sprint?"

You’re not saying no. You’re enabling informed choices. The goal isn't to put up a barrier. Instead, you're trying to find a way to make things work.

Communicate Early and Often

The worst time to say you’re behind is the last day of the sprint. Seriously.

The best time? The first moment you sense it.

You might be afraid to admit you’re stuck--especially if no one else seems to be. But silence doesn’t build trust. Proactive honesty does.

I've seen it time and time again where people try to hide from this. However, the reality is that it ALWAYS becomes visible. Raising awareness that you might be behind, you're blocked, or you might need some help is absolutely not a sign of weakness. It's simply a normal part of building software.

Actionable Tip: Use your daily standups to surface risk. Don't waste your time and everyone else’s with a deep dive status update... Talk about the risks!

"This is taking longer than expected. Here’s what I’ve tried. I might need help."
"I haven’t started on Y yet because I’m still blocked on X. I think I'll need help to get both done on time at this point."
"Can someone pair with me after standup? I think I’m going in circles. I can share what I've tried so far."

Overcommunicate. Your team can’t support what they don’t know.

Don’t Wait for Someone Else to Lead

If you’re thinking:

"But I’m the junior. Shouldn’t someone else be modeling this behavior?"

You’re right. Someone should be modeling it. But they might not be doing it.

A high-functioning team doesn’t magically emerge. It’s shaped by people willing to go first.

Even if it’s unfair, you might need to be that person. Take charge. Lead the way.

Actionable Tip: Be the developer who normalizes sharing struggles. After someone helps you, post in the team channel:

"Shoutout to Alex for unblocking me on the deployment script--learned a ton about our CI/CD setup."

You’re reinforcing a culture where:

Asking for help is normal
Collaboration is expected
Knowledge gets shared

That’s leadership. Even if your title says "junior." People absolutely notice this kind of thing, and it goes a really long way.

When It’s Time to Leave

Let’s be real: not every team is fixable.

If you’ve:

Raised concerns multiple times
Asked for mentorship and got nothing
Highlighted sprint issues with no change

...you’re not the problem. You’re in the wrong environment. And staying in a bad fit stunts your growth and isn’t worth it if it’s negatively impacting your mental health.

I always encourage people to try and put an effort into driving change at first. But I do acknowledge people can only put so much energy into things.

Actionable Tip: Set a time-boxed window--say, 3 months--to try improving things:

Start surfacing blockers early
Ask for pairing or feedback
Suggest smaller, testable sprint goals

If nothing improves despite repeated efforts and raising awareness to your manager, give yourself permission to look for a new team.

At some point, it's just not worth it.

The Takeaway: Growth Requires Voice

You can’t control every team dynamic. You can’t always force mentorship. You can’t magically fix sprint dysfunction.

But you can:

Communicate early
Try to negotiate commitments
Push back with curiosity, not defensiveness
Normalize asking for help and lead by example

Those actions build the kind of team you want to work on. And if you do them consistently? Even as a junior?

You stop just surviving. You start shaping the culture.

And that’s the path to real growth!

Dev Leader Weekly