
Mike Lyons breaks down the Scrum increment: the completed work shown each Sprint that moves toward your Product Goal. Multiple increments can happen in one Sprint, they should be shown to stakeholders throughout (not just at the end), and they only count if they meet your Definition of Done.
Chapters
As a team, we're sprinting along and we're incrementally delivering pieces of value to our product owner, sort of, is this what you want? And we're sharing that as we go throughout the Sprint. Well, those pieces of value, that value delivery, those are part of what we call the increment. And so here we have another one of our artifacts in the Scrum 353, the increment, sometimes called a product increment. It is the empirical data that shows we're making progress towards our product goal. It's a sort of stepping stone, if you will, each step along the way as we're getting to release value and reach our product goal. And there can be multiple increments per Sprint, and we put all of that together in our Sprint review to demonstrate for our stakeholders and customers. But I don't want us to get confused that the Sprint review is like some kind of phase gate and it's the only time where we're demonstrating value. It's not that you can demonstrate an increment to your product owner anytime, as soon as you're finished, sort of, is this what you want demonstrating that as you go throughout the Sprint? And that should remind us of another Agile Manifesto principle. Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter time scale. So again, this increment, it's the sum of all the things we've completed during the Sprint that walk us towards our product goal. Key thing to remember here is it can only be accepted as done when it meets the team's definition of done. So incomplete work wouldn't be part of a product increment. And while Scrum doesn't necessarily call for the release or the deployment of this piece of value, this increment, it should be ready to be released to the users. Your customer may not want to release it to the users, but it should be potentially shippable. So sometimes you'll hear the term potentially shippable increment. All we mean is that it meets the team's definition of done and could be released if the customer wanted to. A way to think of this increment is it's the demonstratable piece of functionality. That's another way to consider increments.










