[regularfry]

I see it the other way round. We're doing Scrum (ish, I guess) right now, and the see-saw between either ending a sprint with a couple of late-night panic sessions to get everything out of the door, or ending it with most of the team kicking their heels with one pair still going up to the deadline is what feels like the slog. I see Kanban as much smoother: I don't see artificial, self-imposed crunch mode every fortnight as a positive. It's all very well aiming at a social commitment, but the way it works in practice is either a) you under-estimate and have dead time; b) you over-estimate and crunch; or c) you nail it and one sprint runs smoothly into the next. The trap is that c) never happens.

I think what makes the difference is that we're continuously delivering, so there's no delivery ceremony between one sprint and the next to make the crunch mode mean something.

[cmdkeen]

The crunch approach to sprints is the killer. If you know you can't complete all the work in a sprint the answer should not be to bust yourself to try and complete it. Have a conversation with yourselves and the product owner to readdress what you can realistically achieve in the time remaining and then do that.

It's a really hard thing to do, we all want to be the hero that saves the sprint. It also encourages you to end up with lots of discrete chunks of work in a sprint so you can complete 80% of your initial commitment and salvage a sense of achievement rather than getting 80% through a few big tasks but none of them actually done.

A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will almost never succeed. A sprint with 4 developers and 20 tasks each estimated to take a day or two stands a much better chance of success. Combine that with some metrics around "complexity per developer per available day" and you quickly end up with some charts showing productivity that is hopefully improving which will hopefully improve morale.

[JoeAltmaier]

Aligns with my experience. We're always continuously delivering, with madeup goals stuck in to align with arbitrary sprints. The real activity takes as long as it takes. Sprints are a stilted reporting structure, adding drama but little real value.

[alistairSH]

...ending a sprint with a couple of late-night panic sessions to get everything out of the door...

My first reaction is you are not sufficiently grooming your backlog. Stories are left too large, with too many unknowns. If you tend to have a small number of large tasks, this is likely the case.

That, or you just aren't very good at estimating. A large number of small tasks would indicate this problem.

In the second case, you need to circle back with the PO and discuss which items can push to the next sprint. And make a concerted effort to estimate better during grooming and planning sessions.

[sandGorgon]

in that case, do you use retrospectives at all ? if you dont have a goal post, then how do you retrospect.