Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

The Sprint Increment Is Dead

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

The Sprint Increment Got Us Here

If you’re a veteran of the software industry, you probably remember those days when we released to production/GA every couple of months. Heck, many of the companies I meet these days still work that way.

If you’re also an experienced Scrum practitioner, you probably associate the time you started to use Scrum with the time you started to release more frequently. The Sprint Increment that had to be potentially releasable caused you a lot of pain as you were trying to improve your processes and capabilities, implement Continuous Integration, and finally gain the ability to actually have a releasable Increment each Sprint. You were pretty proud.

Transcending Scrum and the Sprint Increment?

But these days, as people talk more and more about DevOps and Continuous Deployment, you might be thinking that since Scrum is focused on Sprints, You need to transcend Scrum in order to keep up with the industry and the need to release more often. You start to look at approaches such as Flow and Kanban that are continuous in nature.

Before you recycle your copies of the Scrum Guide – can I ask you a couple of questions though?

The Need For Continuous Deployment

The first question is why do you need Continuous Deployment? Does your Product Owner really see a business need to deploy more often than every Sprint (which is always up to 30 days and more frequently these days more along the lines of 14 days)? If you are like most of the Scrum practitioners I’m working with, the answer to that is “Not Really”. Even cloud/SaaS/internet-based companies typically don’t see a need for releasing new features to market more frequently than every 15 days.

So, why the need for Continuous Deployment?

Scrum Theory helps us out here. The reason is empiricism. In contexts of growing business and technical uncertainty, those with the fastest feedback loop win. And the feedback loop should provide REAL transparency to the usefulness of the products we build so that our inspection and adaptation is based on what users really think of the product we’re building. When we say “Working Software” in the Agile Manifesto, we don’t mean just “It is working and we tested it meets our acceptance criteria and our definition of Done”. We also don’t mean just “It is working and we demonstrated it to internal and even external stakeholders and got their feedback”. These are nice levels of transparency that are much better than just reviewing documentation of course, but they leave a lot to be desiredץ

What we REALLY mean when we say Working Software

They aren’t as good us “It is working, we actually turned it on for some users and they’ve been using it as part of their real flow of work, and we can inspect how useful it really is for them.” The last one is what real transparency is about. And classic teams only get to that level of “working” pretty infrequently. Their REAL feedback loop takes weeks if not months to close. Their level of empiricism leaves much to be desired.

The real reason for moving toward Continuous Deployment is actually to address this issue. To enable much more frequent transparency of how our product is REALLY doing, and enabling inspection and adaptation on a daily and maybe even hourly basis by those developing the software/product.

Continuous Deployment with Scrum and Kanban

In Scrum terms, Continuous Deployment happens during the Sprint, where we can have as many mini-increments as we want deployed throughout the Sprint, with the purpose of helping the Scrum Team optimize the value it delivers with its Sprint Increment. Yes, they could also release some of those mini-increments for the purpose of actually delivering customer value, but most of the time the purpose would be to inspect and adapt, in service of empiricism.

Moving to multiple mini-increments inside the Sprint doesn’t change Scrum in any way. This is actually just a more professional instance of Scrum that more and more Scrum practitioners should strive for. The Sprint-level events are still as valuable as ever for inspecting and adapting the Product and the Process. The roles are still as valuable as ever. If anything, it might be even more important to have a Product Owner that focuses the Development Team on the mission/goal, being open about the fact that there are some hypothesis-level assumptions that need to be validated by building some product and running some experiments, and respecting the developers and trusting them to figure out how to achieve that mission/goal by running fast feedback loops that include actual experimentation, inspection, and adaptation. In order to scale, the Product Owner needs to have the courage to let the Development Team run some of those experiments on their own. They can all review these experiments and the resulting Sprint Increment as part of the Sprint Review. The review will not be just a demonstration of working software but also inspection of analytics from real usage.

Where Kanban/flow comes handy is not in replacing Scrum but in managing the flow of these intra-Sprint feedback loops more explicitly and helping the Scrum Team identify bottlenecks, constraints, and impediments on their way towards this type of flow.

So, yes, the Sprint Increment is dead. Long live the REAL Sprint Increment as well as all the mini Increments during the Sprint.

To learn more about how professional Scrum teams think about flow and Continuous Deployment, join an upcoming Scrum with Kanban workshop.

Subscribe for Email Updates:

Categories:

Tags:

transformation
Daily Scrum
Scrum Primer
Kaizen
Product Ownership
Agile
Continuous Delivery
A Kanban System for Software Engineering
Self-organization
Continuous Planning
Scrum Master Role
Video
SAFe Release Planning
Product Management
Agile Delivery
Legacy Enterprise
Scaled Agile Framework
Development Value Streams
EOS®
Iterative Incremental Development
AgileSparks
Agile Marketing
Professional Scrum Master
Nexus and SAFe
ATDD vs. BDD
Scrum and XP
agileisrael
Jira Cloud
Atlaassian
Nexus and Kanban
Agile Release Management
RTE
LeSS
Agile Project
Legacy Code
Agile Israel
Scrum.org
Agile Outsourcing
Jira Plans
Releases Using Lean
Nexus vs SAFe
Perfection Game
Kanban Basics
TDD
Agility
Managing Projects
Advanced Roadmaps
Jira
Retrospectives
Continuous Deployment
Agile Testing Practices
Lean-Agile Budgeting
Reading List
RTE Role
Tips
Nexus
Lean Budgeting
lean agile change management
Confluence
Operational Value Stream
Agile Techniques
Scrum With Kanban
Certification
ScrumMaster Tales
Nexus Integration Team
An Appreciative Retrospective
Acceptance Test-Driven Development
ROI
Agile Release Planning
Agile Israel Events
Lean Agile Leadership
Program Increment
Entrepreneurial Operating System®
Continuous Improvement
Agile Contracts Best Practices
Agile Mindset
Achieve Business Agility
Kaizen Workshop
DevOps
SAFe DevOps
Frameworks
User stories
Engineering Practices
Coaching Agile Teams
System Integration Environments
Applying Agile Methodology
Elastic Leadership
Limiting Work in Progress
BDD
Scrum Values
Enterprise DevOps
Agile Basics
Managing Risk on Agile Projects
Professional Scrum Product Owner
GanttBan
IT Operations
Sprint Iteration
Agile Risk Management
Amdocs
Lean-Agile Software Development
Agile Project Management
Risk Management in Kanban
Scrum Guide
Portfolio for Jira
ALM Tools
PI Objectives
Jira admin
Pomodoro Technique
Professional Scrum with Kanban
NIT
System Team
ARTs
What Is Kanban
Agile Development
Agile India
AI
System Archetypes
Tools
Introduction to ATDD
LAB
Slides
Agile in the Enterprise
Business Agility
Agile and DevOps Journey
Games and Exercises
ATDD
Change Management
Spotify
Agile for Embedded Systems
Implementing SAFe
speed at scale
Team Flow
Atlassian
LPM
Continuous Integration
Covid19
Kanban
Kanban Game
Lean Software Development
Sprint Planning
speed @ scale
Accelerate Value Delivery At Scale
Artificial Intelligence
chatgpt
Software Development Estimation
predictability
The Agile Coach
WIP
Kanban 101
Code
Introduction to Test Driven Development
Kanban Kickstart Example
Release Train Engineer
Agile Product Ownership
Built-In Quality
SA
Hybrid Work
SPC
Lean and Agile Principles and Practices
Risk-aware Product Development
Effective Agile Retrospectives
Agile Games and Exercises
Quality Assurance
Software Development
Systems Thinking
QA
Lean Startup
Sprint Retrospectives
Agile Exercises
Story Slicing
AI Artificial Intelligence
POPM
Scrum
RSA
Large Scale Scrum
Process Improvement
Value Streams
Presentation
Lean Agile Basics
Agile Assembly Architecture
Keith Sawyer
PI Planning
Scrum Master
Lean and Agile Techniques
Lean Agile
Certified SAFe
Manage Budget Creation
Agile Community
Agile Program
SAFe
Agile Product Development
Lean Risk Management
The Kanban Method
Lean Agile Organization
Agile Games
Principles of Lean-Agile Leadership
Risk Management on Agile Projects
ART Success
Rovo
Implementation of Lean and Agile
Rapid RTC
Lean Agile Management
Planning
Webinar
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart