Updates and Confusion from the Guide

...we could always show the customer. We made it 3/4ths of the way, give us one more week and we'll release, since we're 3/4ths of the way, is there anything you'd like to change or should we just complete as we planned?

How would that feedback be obtained, when no work is Done and fit for release? Where's the empiricism?

In my view there's Always a useful increment of work done every sprint. Now we may choose to release or not to release it based on how much value it's going to bring to the end customer. It may bring value in resolving tecnical blockers - which is valuable but the end user might not see it just yet.

What I've interpreted with "Instead, it returns to the Product Backlog for future consideration" is that this piece of work which was not competed is then assumed to be in the backlog and then taken to Sprint Planning session for the next sprint, and it can be pulled from this backlog into the next sprint. So although not completed in sprint 'n', it might be completed in sprint 'n+1'.

Having said the above, if it was going to be longer than 1 sprint, the dev team should have broken it down (INVEST). But if there were factors outside of the teams control, which resulted in the story not being completed in 1 sprint, then assuming the team did everything in their power to unblock it, it's not the teams fault.

When it comes to Scrum I've always believed it to be both Iterative and Incremental.

This is correct - Scrum is both iterative and incremental. The development cycle, from requirements through design and architecture to implementation and integration and test, is repeated frequently. In Scrum, these activities typically happen every single Sprint. The product is also sliced, and each slice is built and integrated to form the final product.

I did however wrongly interpret that a Scrum team could fail to produce an Increment, but because it was only suppose to be potentially releasable, that it wasn't necessarily an issue.

A Scrum team can fail to produce an Increment. They can also fail to produce a working Increment. However, a Scrum Team should be striving to produce a usable, working Increment every Sprint. Scrum, by itself, cannot guarantee that a team can produce a working Increment every Sprint. The team needs to sufficiently understand the work, slice it appropriately, and have the knowledge and skills needed to implement the slice. Depending on your domain, there are several practices that you can use to increase the chance of producing a usable Increment every Sprint.

I took the potentially releasable part to mean you didn't need to finish the increment every sprint, which to be perfectly honest happened constantly, and I'm having a hard time understanding why that's in fact a requirement from Scrum.

This seems to be a misunderstanding of what it means to be potentially releasable. If something is potentially releasable, there would be no ill effects from releasing it. However, the act of releasing may be too expensive, given the change in value provided by the Increment. If releasing is expensive, the decision may be made not to release the Increment until the change in value between the to-be-released Increment and the last released Increment is more than the cost of releasing.

If we've built the customer a skateboard, and now we're working on making that into a tricycle for the next increment, and we're about half a week behind schedule to hit our next delivery date, we could always show the customer. We made it 3/4ths of the way, give us one more week and we'll release, since we're 3/4ths of the way, is there anything you'd like to change or should we just complete as we planned?

This is still Iterative, and still Incremental.

What you describe could be seen as iterative and incremental, but it's not Scrum. This description is missing a few aspects of Scrum, primarily the Sprint. The Sprint is the timebox in which a new, usable Increment is produced. There are other iterative and incremental process frameworks that may have different rules about how long an iteration is or if an iteration is of a fixed length, but Scrum calls for an iteration length of no more than one month and generally fixed-length iterations (although the length can be changed if it makes sense, it's not decided on a per-iteration basis).

Fast forward to the 2020 guide:

"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."

This seems to put a hamper on the Incremental part in a weird way. Now, I'm hitting the 2 week window of our arbitrary cadence, and I'm saying to the customer, well... We failed, and we have nothing to show for it. We'll do better next time, and I think you'll be happy...

This doesn't change much in the context of Scrum, as far as incremental development goes. This is simply a clarification of the intent of previous versions of the Scrum Guide. As far as I know, Scrum has always called for a usable, working product Increment at the end of every Sprint. The new definition makes this a little more clear and ties in the Definition of Done.

If the team is failing to produce something that is considered usable Increment at the end of every Sprint, they should be using the Sprint Retrospective to figure out why and what changes they can make to be able to do so regularly. There may be times when the team can't get anything Done, but that should be the main retrospective topic.

I do feel that the inability to present incomplete work at the Sprint Review is a bad change to the framework. In the 2017 Scrum Guide, the Sprint Review description stated that the Product Owner would discuss the work that was Done and not Done and that the Development Team (now the Developers) would discuss problems it ran into. These do leave some room for the opportunity to talk about work-in-progress and decide on the right course of action.

@ Ian Mitchell



I think that's obvious, where is the confusion? I showed you a tricycle with 3 wheels, a frame, it even has the handle bar, just no handles and it's not painted. You could easily provide feedback on what you're able to observe at that time. 



Turns out the customer doesn't like the spokes on the wheels, and wanted the handle bar an inch higher. We added that to our next sprint, and made a few adjustments before completing the original handle's and paint... 

@Thomas Owens

A Scrum team can fail to produce an Increment. They can also fail to produce a working Increment. 

Then why isn't that in the scrum guide verbiage? I don't see any interpretation where the Scrum Team could fail to release an increment and still be considered Scrum, especially in the 2020 guide, it makes it impossible to even demo it to the customer. 

In the 2017 Scrum Guide, the Sprint Review description stated that the Product Owner would discuss the work that was Done and not Done and that the Development Team (now the Developers) would discuss problems it ran into. These do leave some room for the opportunity to talk about work-in-progress and decide on the right course of action.

Yes, and that made sense, but in the 2020 guide it's almost contradictory: "The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." - "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."

Does this mean they CAN show something that didn't meet the definition of done or not? I assume no, which makes any "failed" sprint a complete loss, even to the attempt to be retrospective. 

The product is also sliced, and each slice is built and integrated to form the final product.

This also concerns me a little bit, Incremental delivery was described to me as an evolving product that while may have stages of delivery, example often used would be a single page of a website, or even just a single function on a web page. But, as we get to the next feature, or page, aren't we evolving from the original design based on feedback, thus making it incremental? I'm afraid if we just define incremental delivery as delivering in pieces, that opens the ability for companies to say, oh I'll just cram this already completely defined product into iterations, only release it at the end, and call it Scrum... If that is indeed Scrum, then I think Scrum has shifted away from Agility and that makes me sad.

What am I missing?

Does this mean they CAN show something that didn't meet the definition of done or not? I assume no, which makes any "failed" sprint a complete loss, even to the attempt to be retrospective. 

I am going to be a bit "literal" with my answer so bear with me. 

From the 2020 Guide section on the Increment

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration

From the 2020 Guide section on the Sprint Review

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.

So any increment that does not meet the Definition of Done can't be released, can't be presented at Review and should return to the Product Backlog for future consideration.  I get that.  But there is no reason that the work can't be discussed at the Sprint Review since the purpose of that event is to "inspect the outcome" and "review was accomplished".  But you wouldn't present unfinished work since it is not ready for the user.  You also wouldn't release unfinished work.  But you might not want to release finished work either if the increment that is completed is not enough for the stakeholders to start using. 

Does this make sense? 

I think that's obvious, where is the confusion? I showed you a tricycle with 3 wheels, a frame, it even has the handle bar, just no handles and it's not painted. You could easily provide feedback on what you're able to observe at that time. 

Is it Done and fit for release?

@Daniel Wilhite

Okay, so in my scenario of the Tricycle, you're saying the wheels / frame / bar are finished, but the handles and paint are not finished. So, essentially, that story needs to be dissected into smaller stories, the ones that are finished can be presented, but the ones that are not are put back on the backlog. Then, as a whole you can say that you weren't able to finish all of it, but could illicit feedback on the parts completed?

I don't see how that can line up with:

"An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable."

"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.."

This seems to imply that you cannot dissect your increments, but you can release multiple increments per sprint. In my scenario, if you failed to complete the Tricycle in the sprint, it's a net loss and the only discussion you can have is that you didn't meet the sprint goal, and as it stands from a backlog perspective, you're 3/4th's of the way through with it. 

I just find the verbiage being used almost intentionally convoluted, this really seems like a simple thing, allow the customer to see the parts not done, the parts done, and allow your developers to work on them in pieces but require them to be assembled to be called an increment.

I know I'm being very literal, but this is the kind of stuff that gets thrown in a SM's face when he's trying to make a point to the team, and I've had to try and defend myself using the scrum guide on many occasions, I want to make sure my arguments are sound before I have to go into a meeting with that potential. 

@Ian Mitchell

Is it Done and fit for release?

No, clearly the increment is not finished, the definition of done is not accomplished. The scrum team has failed. Is that the intended constraint? We want Scrum teams to view any inability to deliver a fully finished increment in a sprint to be this way?

Is that the intended constraint?

More than that: to better serve empiricism and the Scrum values, "Done" is the intended commitment.

The Scrum Guide says:

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

• For the Product Backlog it is the Product Goal.

• For the Sprint Backlog it is the Sprint Goal.

• For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Then why isn't that in the scrum guide verbiage? I don't see any interpretation where the Scrum Team could fail to release an increment and still be considered Scrum, especially in the 2020 guide, it makes it impossible to even demo it to the customer. 

Daniel Wilhite's response is spot on. The revisions to the Scrum Guide call for not presenting work-in-progress at the Sprint Review, but the Sprint Review has other aspects to it. One aspect is "to inspect the outcome of the Sprint". If the outcome of the Sprint is a failure to achieve the Sprint Goal and failure to produce a working Increment, that is something that can be inspected. The Sprint Review is also an opportunity for the stakeholders in attendance to "collaborate on what to do next". Likewise, figuring out the next steps doesn't require a working Increment.

It is important to realize that the Sprint Review is not (just) a demonstration. It's an opportunity for inspection and adaptation of the product and the Product Backlog (including the Product Goal). Even if you don't have anything to demonstrate, you can still inspect where you are now and adapt your next steps to maximize value.

Yes, and that made sense, but in the 2020 guide it's almost contradictory: "The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." - "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."

Does this mean they CAN show something that didn't meet the definition of done or not? I assume no, which makes any "failed" sprint a complete loss, even to the attempt to be retrospective.

According to the 2020 Scrum Guide, work that does not meet the Definition of Done cannot be demonstrated. However, I don't agree with this change. Even if it results in "not Scrum", I'd have an open discussion with the team about what the impact of this is. As long as the stakeholders understand that the work is not Done and is still a work-in-progress, demonstrating it and talking about it can help to more effectively plan the next steps. Ultimately, the team or organization should own their way of working and do what is best for them, even if the choices result in "not Scrum".

This also concerns me a little bit, Incremental delivery was described to me as an evolving product that while may have stages of delivery, example often used would be a single page of a website, or even just a single function on a web page. But, as we get to the next feature, or page, aren't we evolving from the original design based on feedback, thus making it incremental? I'm afraid if we just define incremental delivery as delivering in pieces, that opens the ability for companies to say, oh I'll just cram this already completely defined product into iterations, only release it at the end, and call it Scrum... If that is indeed Scrum, then I think Scrum has shifted away from Agility and that makes me sad.

Not all forms of incremental delivery are the same. Yes, it's true that Scrum is incremental, but it also adds other rules. The Product Backlog Item is the core unit of value in Scrum. Each Product Backlog Item is something that can be designed, implemented, integrated, tested, and usable by a stakeholder. The 2020 revision of the Scrum Guide made it clear that a new Increment is formed every time a Product Backlog Item meets the Definition of Done. A single feature or page may not add sufficient value or meet the criteria to be a Product Backlog Item, so even if a page was done, the Product Backlog Item may not be Done.

Okay, so in my scenario of the Tricycle, you're saying the wheels / frame / bar are finished, but the handles and paint are not finished. So, essentially, that story needs to be dissected into smaller stories, the ones that are finished can be presented, but the ones that are not are put back on the backlog. Then, as a whole you can say that you weren't able to finish all of it, but could illicit feedback on the parts completed?

That is almost what I intended to convey and thanks for asking for clarification. (It helps me get better at this). 

It really depends on what your Definition of Done states and whether the paint and handles would have to be included to meet the Definition of Done.  If your story was to deliver a tricycle then you finished that story. If it was to deliver a tricycle with handles that match the paint job, then you didn't quite finish.  So I'd put that story back into the Product Backlog and discuss the progress with the stakeholders during the Sprint Review. You could show them the tricycle in order to foster discussion but don't present it as done because it isn't.  The discussion that ensues could determine that it is good enough without the handles and paint since your ultimate goal is a self-driving car.  Or it could determine that you are wasting your time doing anything with wheels because their needs have changed to needed pontoons so that it can be used on water.  This is where the inspect and adapt loop of empiricism comes into play.  My way of explaining it is "do something, look at it, decide if something needs to change and something else, repeat until it is good enough".  

The Definition of Done applies to the increment which is the combination of all the work that is determined to satisfy the definition.  From the 2020 Guide section on the Increment

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

In my opinion you could finish a story but due to dependencies between stories you haven't met the Definition of Done.  As the second statement illustrates an increment is not born until the Product Backlog item satisfies the definition.  Some companies might write stories for your tricycle as "build a frame", "attach wheels", "attach handlebars", "attach seat".  The Definition of Done for the increment would be "have a tricycle that someone can sit on and steer as it rolls".  None of the stories meet the Definition of Done until all of the others are complete. So at the end of the Sprint you might not have a completed increment if the seat isn't attached. But you could still discuss the work that was done with the stakeholders. 

I don't think that your story needs to be broken down any further but it might be something that the team decides they want to do going forward based on the situation encountered.  I would check with the stakeholders to see what if their expectations meant the handles and paint would be included.  If not, it could be a problem with your Definition of Done and not the stories themselves. You could write the next set to add a motor to the tricycle and deliver a working model.  Leaving out the detailing of pedals, handles, paint is a valid choice especially since you may uncover changes that would make changing the paint job necessary. The Definition of Done would be written to clearly convey the quality measures required for the product, keyword being clearly.  This is also an example of inspect and adapt.  The product isn't the only thing that can benefit from the iterative, empirical approach.  Process is much more successful when you empirically adapt it. 

Good discussion by the way.  Thanks for challenging us. 

I've leaned on this forum as a guide in a lot of my discussions and challenges throughout my relatively brief career in the last 3-4 years. I find the discussion extremely beneficial and appreciate all of your responses. I think I have a much better understanding now. Thank you all. :)

This site has a bundle of knowledge. Here I got mostly all types of knowledge. I also have something to share with friends. I also want to write such a beautiful article.