I’m a Scrum Master working with a software development team, and after our latest retrospective I’m seriously questioning whether Scrum is still helping us or whether we are maintaining the framework mostly because it is our established way of working.

I’d especially love opinions from both Kanban practitioners and very orthodox Scrum people, because I want someone to challenge our reasoning rather than simply confirm that Kanban sounds better.

Context

We work on an academic management system with many different modules and stakeholders/user areas.

Our Sprints are two weeks long.

Over time, the team has started working on several modules in parallel. One Sprint might heavily focus on Module A, the next Sprint on Module B because it became more urgent, and two Sprints later we return to Module A.

This is creating a continuity problem.

From the user's perspective, they asked for Module A weeks ago and eventually ask:

"Why isn't this finished yet?"

From the team's perspective, the answer is:

"Because it wasn't actually our focus continuously during those weeks."

During our latest retrospective, the team explicitly raised that they feel we are constantly switching context and that the Sprint boundary sometimes creates an artificial sense of starting/stopping work rather than helping us finish what we already started.

Another important point: we already use WIP limits.

So this isn't simply a case of "you need to stop starting and start finishing." We've already been experimenting with limiting WIP and analyzing how much simultaneous work the team can sustain.

Planning and commitment are becoming another pain point

One of the strongest comments from developers was that sometimes the sequence feels like this:

Request → commitment → analysis of how to build it

instead of:

Request → analysis/discovery → conversation between PO + Developers → decision/commitment → development

They feel that by the time they are properly discussing how something should be implemented, there is already an expectation that it will be done.

We discussed shared responsibility here.

The PO needs to involve Developers earlier and ask what is actually viable before creating expectations with stakeholders.

At the same time, Developers acknowledged that they also need to become better at saying:

"No."

"Not yet."

"We need to analyze this first."

or:

"We could commit to X, but not Y."

So I don't see this as simply a PO problem.

We also have a stakeholder/Review problem

Users request developments and put significant pressure on the team because something is supposedly urgent.

We develop it.

Then Review arrives... and sometimes those same users don't attend.

So now we need another meeting on another day to actually get the feedback we needed from the Review.

This has started a discussion around whether we're becoming too focused on maintaining the Scrum calendar rather than optimizing for actual stakeholder feedback.

For example, right now we're discussing a schedule that could look like this:

Thursday: development cut-off
Friday: Sprint Retrospective
Monday 10:00: Sprint Review with stakeholders
Later Monday: Sprint Planning

This obviously alters the usual sequence of Sprint events.

The reasoning is practical: Friday may work better for the team's Retro, while Monday gives us a much better chance of getting stakeholders into the Review.

But then the Scrum question becomes interesting:

If we "close" development on Thursday and Retro on Friday, but the Review is Monday and Planning happens afterward, where exactly does the Sprint end?

Are we creating an artificial "cut-off" that has no real meaning in Scrum?

Would an orthodox Scrum interpretation simply say:

Review → Retro → next Sprint Planning, and stop trying to rearrange the events around stakeholder availability?

Or is adapting the calendar reasonable if it results in substantially better stakeholder participation?

I'm genuinely interested in the strict Scrum interpretation here.

The team is now asking about Kanban

The Developers — and even the PO — have repeatedly mentioned that they would prefer something closer to:

Prioritized backlog → available capacity → pull next work item → finish → pull next item

instead of spending significant time every two weeks deciding how many work units we are going to "commit" to.

Their argument is essentially:

"If the backlog is already prioritized and we have a WIP limit, why don't we finish something and pull the next highest-priority ready item?"

They believe this could give them more continuity and reduce the feeling that every two weeks we reset/reorganize the work.

One concern I raised during the Retro was individual productivity comparisons.

I explicitly told them:

"If we move toward pulling work continuously, I don't want this turning into 'I completed 20 work units and you completed 12', or developers competing to pull more work."

The team strongly said they don't want that either.

My position would be that work units remain a planning/flow tool and never become an individual productivity metric.

Another issue: we start new developments before properly finishing existing ones

This also came up very strongly.

We have several important modules/products currently competing for attention, and during the Retro we actually created a global priority order.

The team is basically saying:

"Can we please finish more of Priority 1 before opening Priority 4, 5 and 6?"

This is one of the reasons Kanban is becoming attractive to them.

We are also considering changing how we manage stakeholder expectations

Instead of a stakeholder asking for something and immediately creating an expectation of a functional development, we discussed using:

Request → discovery/analysis → mockup or visual proposal → stakeholder feedback → functional development

when appropriate.

In other words, sometimes our first commitment should be:

"We'll show you what this could look like."

rather than:

"We'll build it."

We also want waiting for stakeholder feedback to become explicitly visible in our workflow rather than having development appear "unfinished" while the team is actually waiting several days for someone to validate something.

So now I'm stuck between three possibilities

1. Keep Scrum and fix our Scrum implementation.

Maybe Scrum isn't the problem at all.

Maybe our actual problems are too many concurrent initiatives, weak refinement/discovery before commitment, stakeholder availability, priority changes and poor expectation management.

2. Keep Scrum but deliberately introduce more Kanban practices.

We already have WIP limits, but we could go much further with flow management, pull policies, explicit workflow states, aging/cycle time, blocked/waiting states, stronger policies around when new work can enter, etc.

Then after a few Sprints ask:

"Is the Sprint still providing value?"

3. Actually move to Kanban.

Remove the artificial two-week commitment boundary and manage work through continuous pull, explicit policies and flow metrics, while keeping useful cadences for retrospectives, replenishment, stakeholder feedback, etc.

I'm deliberately resisting jumping straight to option 3 just because the team is frustrated with Sprints.

I want us to understand whether Kanban actually matches the nature of our work better or whether we're expecting Kanban to solve organizational problems that will follow us regardless of framework.

My questions for you

For the Scrum purists: what in this story makes you think "your problem isn't Scrum, you're just not using Scrum effectively"?

For Kanban practitioners: what signals here genuinely suggest that Kanban might be a better fit?

Would you experiment first with Scrum + Kanban before considering dropping Sprints?

What would you measure during that experiment to make the decision based on evidence rather than preference?

And what do you think about the proposed event schedule:

Thursday cut-off → Friday Retro → Monday Review → Monday Planning?

Is that a reasonable adaptation, or are we breaking an important inspect-and-adapt feedback loop by holding the Retro before the Review?

Finally: if you were the Scrum Master in this situation, what would you change first?

I'm completely open to being told that I'm overcomplicating this, that we're doing Scrum badly, that Kanban would fit better, or some combination of all three.

I mostly want to understand what problem we should actually be solving.

Measuring a team’s throughput can be useful. But throughput of what?

High throughput does not guarantee that you are creating value. It is only a leading indicator — not a measure of value itself.

A leading indicator is a clue that you may be moving in the right direction. It has to be interpreted alongside health metrics and lagging indicators that show whether meaningful outcomes and value are actually being created.

Ultimately, the best measure is the value created compared with the money spent. That could be revenue generated, but also another outcome that matters to the organization: children vaccinated, people lifted out of poverty, and so on.

But as an early signal, what should throughput be based on?

I have tried several approaches. So far, my preferred one is the number of acceptance criteria completed per week.

Of course, that only works if the team knows how to write and use acceptance criteria properly. A well-written acceptance criterion should define how to validate the expected user or business value, rather than merely describe a technical function. It should also be solution-agnostic.

What do you think?

The brightidea pricing structure is built on an app model where each capability requires its own subscription

Starting cost looks reasonable and then the program grows, a new department wants challenge management, another needs portfolio reporting, and each one is a separate line item

Budget predictability goes out the window the moment the program expands past the initial use case

Hello everyone!

I'm looking for people currently managing projects across tools like Jira, GitHub, Slack, Notion, spreadsheets, etc.:

I'd like to receive your feedback on things like:

• What do you still have to check manually across multiple tools?
• What information is surprisingly hard to get?
• What tends to fall through the cracks?
• What do you wish was automatically surfaced or summarized?
• If you could magically add one cross-tool functionality, what would it be?

Interested in both small annoyances and bigger workflow problems.

Would love to hear what your ideal setup would look like.

thank you for your time and have a great week!