[human20190310]

Sprints to me seem completely contrived.

In reality, there are only things that people are working on, and things that no one is working on. There's no need for a third category of "things that are in the sprint" as long as someone (anyone!) keeps the task queue sorted in priority order.

[all_usernames]

Sprints are meant to be a tool to measure a team's velocity, defined as average amount of work throughput in X weeks. You don't know the average until a sprint team has worked together for several sprints on similar work.

Sprints can work very well if you need to:

A) Estimate the time it will take to complete a large project B) Compare productivity of different teams so you can shift or add people C) Get continual feedback on the work quality and the workflow process

Over time, I've seen sprint teams become very accurate at estimating their work throughput ahead of time. This can be extremely valuable to the business delivering on its goals on time and committing to the right amount of deliverables.

[pflenker]

Sprints are less about categorizing the incoming work, but partitioning the outgoing work, to establish a quick feedback loop. This should in theory ensure that risks are tackled early.

[human20190310]

The outgoing product is nevertheless fully determined by the incoming work being done. It would make more sense to group a set of tasks into a deliverable than a time period. You have to do that anyway to deliver anything coherent.