Developer Roundtable: Sprints, Cadence, Deliveries and Demos

What’s a Good Sprint Cadence, Anyway?

Sprint length. Estimating work. Getting stories over the line. These are the kinds of things that sound straightforward in theory but, in practice? They can get messy fast.

If you’ve ever found yourself in a sprint meeting asking, “Wait, why are we even doing this right now?” You’re not alone. This developer round table was a bit of a brain dump, a reflection, and hopefully a helpful mashing of perspectives for anyone navigating the world of sprints, project management, and product delivery in the real world.

The Not-So-Straightforward World of Sprints

“How long should our sprints be?”

It’s one of those questions that sounds like it should have a clean answer. One week? Two weeks? Just pick something, right?

But the truth is: it depends.

Project management isn’t just about moving tickets. At its best, it helps teams and clients stay aligned on what’s being built, when it’s coming, and why it matters. But when you’re in the thick of it, juggling stories, shifting priorities, firefighting bugs, all that clarity can go out the window.

It’s often not obvious when to end a sprint, when to start one, or which stories should be included. And every team, company, and product pipeline is different. Some organizations can go from idea to production in a day. Others might take weeks. That impacts sprint cadence in a big way.

You might see stories constantly rolling over, which can look like a problem in a sprint report. But in reality, it’s just how the delivery pipeline works. If that nuance isn’t communicated, it can lead to the wrong conversations and misplaced assumptions.

Estimation, Rollovers, and That “Gut Feeling” of Progress

Estimates can help. They give everyone, from devs to PMs to stakeholders, a rough sense of how much work is being taken on in a sprint. But they’re only useful if they reflect reality. Overestimate everything and it looks like you’re moving slowly. Underestimate and the team appears overloaded. Neither tells the full story.

That’s why consistent communication matters. Rollovers, blocked stories, shifting scope, these things happen. But if no one talks about why, it just looks like things aren’t getting done.

And that leads to frustration, from leadership, from clients, and often from within the team itself.

The User Is a Wildcard

Another layer of complexity? The end user.

You can design a feature with a clear vision of how people should use it, only to watch users interact with it in completely unexpected ways. And when that happens, you have to go back, rework things, build guardrails, rethink assumptions. That adds time. It adds stories. It shifts priorities. And all of that impacts sprint delivery.

During a discussion after a user testing session, a co-worker shared this image:

You can design and build a cup for the user to hold and drink their water from, and it makes perfect sense to you in your head, but at the end of the day, a user is going to be confused and do things unexpectedly.

But that’s part of the job. The user is unpredictable. Trying to control every edge case upfront usually isn’t realistic, but you can build in space to adapt when the unexpected happens.

So… Why Are We Doing This?

One of the most valuable questions you can ask in any sprint, meeting, or project is:
“Why are we doing this?”

Why are we working on this story? Why did we estimate this as a 3? Why are we spending time discussing this right now?

These questions cut through the noise. They stop us from defaulting into “we’re doing it because it’s what we do” mode. They bring us back to the core purpose of the work.

It’s not about challenging every decision, it’s about being intentional. Are we working on the right things? Do we understand the impact of what we’re building? Is this work still aligned with what the client or business actually needs?

No process is perfect. It takes time to figure out what works for your team. And yeah, there’s always pressure, especially around the ever present pressure of “return on investment”. But good processes take time to prove their value. You have to let them breathe before judging if they’re working.

Trust Builds Breathing Room

A final piece that often gets overlooked: trust.

When leadership or clients trust the team, they’re less likely to panic over timelines or jump to conclusions based on one report. That trust creates space for the team to course-correct, adjust scope, and make smart decisions without constantly needing to justify every step.

And that space? That’s where real progress happens.

TL;DR:
There’s no perfect sprint cadence. Your process will evolve. Things will change. But if you stay intentional, communicate often, and focus on why the work matters, you’ll figure it out.

---

Enjoyed this content? Join our developer roundtable, we meet every other Friday from 10:30 - 11:30 am CT. Hope to see you there!

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.