DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > Multiple Increment Delivery Within a Sprint

Multiple Increment Delivery Within a Sprint

Ken Schwaber addresses a couple of questions that he was asked about Continuous Delivery, Scrum, and how to utilize Sprints.

Ken Schwaber user avatar by
Ken Schwaber
·
Oct. 23, 16 · Agile Zone · Opinion
Like (3)
Save
Tweet
5.77K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Sprint (software development) Delivery (commerce)

Published at DZone with permission of Ken Schwaber, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 12 Modern CSS Techniques For Older CSS Problems
  • Automation Testing vs. Manual Testing: What's the Difference?
  • What I Miss in Java, the Perspective of a Kotlin Developer
  • DZone's Article Submission Guidelines

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo