Scrum Without a Fixed Timebox

[Scrummando]

I know this kind of fringe but something I keep comming back to as I move to more Flow based metrics and a way from velocity. I look at flow in weekly increment. So team X does 5 stories a week as a trend. As a team understands what a product owner wants in a feature and breaks down the work in to stories you may see that we can deliver that in a 1 week or may be 3 weeks. A lot of companies like a 2 week sprint so that has a team looking to fill a sprint with stuff for a week in the first range or in the second filling a full sprint and half the next. You end up with add stories in the fill the second week of second sprint.

Planning sprints becomes about value chunks instead of value + some stuff that fits.

I would still cap all value chunks at 4 weeks, ceremonies would be held still and would not recommend this to brand new teams.

Would love to hear some opinions

[MattMorgis]

I asked a similar question in this thread:

Thoughts on Scrum-ban Approach?

Continuing the discussion from Agile in Education: I'm certainly looking for some advice on a shift in approaches I am considering from Scrum to a Scrum-ban idea. I'll start off by giving some background and context. In early 2015 I discovered Scrum, bought in, and attempted to apply it to my freelance business and with my team at my day job. Despite the few typical obstacles you face in a large enterprise, I feel as if our team is humming along nicely for the past 6-8 months, and over the …

We removed the time boxes and it’s worked out great! We still hold consistent demos and just show what’s completed at that point, rather than stressing to meet to a goal. We still hold consistent retrospectives to improve as a team. And we still have a daily stand up/planning meetings and heavily depend on the board and backlog.

The time boxes were good to get started, but I think in the end mature teams can remove them to be a little more flexible.

[andycleff]

Why get hung up on what we call it? If it works, and the team is predictably delivering value, and the stakeholders are more happy than not, JFDI.

My experience seems similar to @MattMorgis - “Scrum by the Guide” is useful like training wheels are on a bike. Once a team has the basics down, they can explore, experiment and likely have better performance (and a few skinned knees along the way) if the constraints are relaxed.

And it helps to have first aid kit around (Coach) with some triple antibiotic as needed!

[AgileTx]

This makes sense, and I have teams doing something very similar. The big difference, we do not use Scrum Activities. We do follow a weekly cadence for stakeholder reviews. Other than that, this approach seems more like Kanban, which I found works equally well.