Multiple Increment Delivery Within a Sprint

I recently had the following exchange that may fill in some gaps in understanding how to use Scrum:

You have been quoted in PSM classes as saying, "a Scrum project is only one Sprint long. A release of software may be the sum of multiple increments (and previously developed software, if any), or there may be multiple releases of software within a Sprint. A Scrum project cannot fail, only deliver an unacceptable return on investment."

I have a question about the part that says, "or there may be multiple releases of software within a Sprint."

• What did you mean by it?
• Is that an answer to how Continuous Delivery works in Scrum?
• What is the sense of the review in Scrum when we deliver before the end of the iteration?
• Is the role of the review to inspect the impact of the value delivered during the Sprint?
• Should we have mini reviews within the Sprint?
• What impact does the early delivery on the Sprint plan have on the stability of the Sprint?

We managed the complexity of Scrum in timeboxes.

• When there is a need to deliver faster, why shouldn’t we shorten the Sprint, even to one day?
• Why couldn’t the Sprint length be dynamically adapted during the Sprint (I don’t mean sprint termination)?
• When I read your initial quote, I ask: aren't we close to Kanban, then, maybe?

Thanks,

Anonymous

Questions followed by my replies:

1. Is that an answer to how Continuous Delivery works in Scrum? That is a way that continuous or frequent delivery can be done within a Sprint.
2. What is the sense of the review in Scrum when we deliver before the end of the iteration? We choose what to set as the goal and focus for the next Sprint, as well as whether to fund the Sprint or not. Reviewing software is part of that decision.
3. Is the role of the review to inspect the impact of the value delivered during the sprint? It could be, or it could be just to see if the Product Owner can see it potentially being useable.
4. Should we have mini reviews within the sprint? That's not a bad idea. Nothing in Scrum prohibits it.
5. What impact does the early delivery on the Sprint plan have on the stability of the Sprint? They probably become more dynamic, but they do not shorten the sprint.
6. When there is a need to deliver faster, why shouldn’t we shorten the Sprint, even to one day? Go to a biology laboratory and see what rats going around in a wheel look like. A one day Sprint has a lot of overhead, as well as having to continually refocus. Bad idea.
7. Why couldn’t the Sprint length be dynamically adapted during the Sprint (I don’t mean sprint termination)? The idea of Scrum is to grab a chunk of chaos and make it malleable to some degree of control. Your suggestion removes that and causes people to have to rethink prior decisions too often.
8. When I read your initial quote, I ask: aren't we close to Kanban, then, maybe? If they are in a complex situation and try Kanban, they have instituted functional swim lanes and removed cross-functional dialog. Then, they start with the metrics and optimize within the Sprint, rather than doing the best they can. Remember that the strength of Kanban is managing to optimize regular but complicated operations, not complex, unpredictable creative work.

Scrum on.