[olah_1]

Correct me if I’m wrong, but Sprints only make sense for teams with more than, say, 4 engineers.

Because a Sprint is fundamentally about estimating bandwidth. You look at the old Sprints and are able to average out some kind of true estimate of capability, right?

But if you have a smaller team, everyone basically already knows what your bandwidth is.

[davidham]

I would say that a sprint is fundamentally about delivering a valuable Increment. Something useful, some kind of meaningful progress. You can start to use past performance as a way to estimate what you'll be able to do in the future, but only with a stable team that has been estimating its own work for a while.

[olah_1]

The problem is, you don’t need a sprint system to do an incremental release.

Fundamentally, Sprints run parallel to incremental releases and are not supposed to be synced with them.

For example, a Sprint is once every 2 weeks. But the next product release could be determined whenever a certain feature is completed.