Skip to main content

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

Last post 09:49 pm January 10, 2023 by Vladimir Jovanović
11 replies
10:37 pm June 7, 2021

Hi, according to Scrum Guide 2020 "The moment a Product Backlog item meets the Definition of Done, an Increment is born". We all know that. And we know that it is required to produce at least one usable increment every Sprint.

But what if one of the PBIs is not releasable? What if it's just an experiment / mockup / internal PoC? There is a value in it, but it is not usable. Is it still part of the Increment?

 


06:39 pm June 8, 2021

An experiment / mockup / internal PoC could be an enabler through which usable work becomes better understood. If so, it might actually be a refinement activity.


07:40 pm June 8, 2021

 And we know that it is required to produce at least one usable increment every Sprint.

Do we know that?  Where in the Scrum Guide does it actually say that? The guide does state 

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

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Multiple Increments may be created within a Sprint. 

But no where can I find that there is a requirement for at least one usable increment every Sprint. 

There is also no requirement that every Product Backlog Item pulled into a Sprint Backlog has to deliver customer facing value.  As @Ian Mitchell states there are many ways that internal value can be created during a Sprint. Most of those would never be expected to release but value is derived. 

The increment is defined as such in the Scrum Guide

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.

Notice that it never mentions that the value has to be to the end user.  Notice that it never says it has to be deployable to Production.  Notice that is says an increment must be usable but doesn't say usable by an end user.  In fact, the Scrum Guide only uses the word "user" one time

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Sometimes the well-defined users or customers could be internal people or services.  And the value to the internal user or customer is the knowledge gained by doing the work. The guide uses "stakeholders" to indicate the target for the value.  Sometimes your Sales organization could be a stakeholder in an experiment or System Operations a stakeholder in a Proof of Concept for new technology.  This is still work that provides value for the Product and can be done on an incremental basis.  

Does that make sense?


08:04 pm June 8, 2021

It makes Daniel, although I used "required" as a thought shortcut. I thought it would be clear ;)

It makes me wonder that this kind of Increment may not be "additive". Can be done in a separate branch and never merged back.

Also I see a bigger issue with DoD which doesn't make sense / should be different for that kind of PBIs. And DoD is on the product level, not product level. Isn't it a problem?


08:26 am June 9, 2021

We are required to do our best to prepare at least one valuable, useful increment - this was my intention ;)

It makes perfect sense Daniel Wilhite. But in that case, I see additional issues:

  • DoD is on a product level. I see a risk that DoD wouldn't make sense for PBIs that are not releasable.
  • Experiment wouldn't be purely "additive". What if we make them in a separate branch? Next Increments wouldn't contain it.
  • It reminds me of "sprints 0" and working on infrastructure, instead of focusing on value delivery outside the team.

I would prefer Ian Mitchell's interpretation, that it might actually be a refinement activity. Although in that case it is not a PBI, just some activity in the Sprint Backlog, right?


05:50 pm June 9, 2021

In my opinion and what I coach is that experiments and things like them are not expected to contribute code.  They are expected to contribute knowledge.  So the code that is used should never be expected to be merged into product branches.  Yes, there are times that the code could be but that should made clear as an expectation when the work starts.  The information you gain can be included in the work done on the product and thus be included in future increments.  

The Scrum Guide uses this statement as the opening for the section that discusses the Definition of Done

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

This doesn't say it is entirely focused on the code that is written.  I have often seen Definitions of Done that include clauses that may not be met by all work done. You can include statements such as "documentation is updated" or "Product Backlog is updated with any remaining work". Experiments can provide information that is applicable to both of those.  But the "code is deployed to Production" may not be applicable.  This all depends on how the Definition of Done is documented by the team.


08:19 pm June 11, 2021

All clear. Thanks for sharing it ☺️


03:09 pm June 15, 2021

@daniel I am not sure what you mean by this:

 

And we know that it is required to produce at least one usable increment every Sprint.

Do we know that?  Where in the Scrum Guide does it actually say that? The guide does state:

 

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.  Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. Multiple Increments may be created within a Sprint. 

 Do you mean that there is no requirement to build increment every sprint? I believe, whatever you do: much architecture work, technical spikes, other r&d work, go Holiday, whatever - but you should deliver at least very small product increment each sprint, to not miss inspect&adapt opportunity. Could somebody comment on this?


03:43 pm June 15, 2021

What I mean is that the Scrum framework doesn't require, it recommends that there be an increment.  It is the goal of every Sprint to deliver one or more increments but there is no requirement.  If there is not one or more increment produced in a Sprint, there is an opportunity for the team to inspect why that happened and adapt for the future.  The increment is a Sprint Artifact and just like all the artifacts is subject to inspection.  

So I feel that not creating an increment in each Sprint is not a failure to follow the framework unless you refuse to inspect what that situation occurred. 

Also want to leave with this thought. From the end note of the Scrum Guide

While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

If you never expect to create an increment, then you are not using the Scrum framework. But if for some reason an increment is not created, it is an opportunity for inspection and adaption and not a failure. 


05:13 pm June 15, 2021

It's important to go into Sprint Planning with the genuine, serious, honest-to-God intention of producing at least one Done Increment of usable quality no later than the end of that Sprint. The act of doing so is the only way for empirical process control to be maintained. If at any given time it no longer makes sense to use the latest Increment then there is no obligation to provide it. Scrum would never force a team into doing the wrong thing.


10:55 am June 16, 2021

many thank. clear and agree. saying it is REQUIREMENT could force sometimes the team to decrease transparency, quality, whatever else to deliver increment, instead of the opportunity to inspect why increment weren't created and adapt, accordingly. 


09:49 pm January 10, 2023

Also I see a bigger issue with DoD which doesn't make sense ...

I could also relate to this.



I was wondering, what if the Scrum Team's DoD is (inadvertently, for whatever reason) weak, and does not contain the standard/measure which will ensure that the Increment is releasable, or that the Increment from a Sprint integrates well with the Increment from a previous Sprint? 



You could argue that since the Increment is not made transparent and empiricism is impacted, the Scrum Team has another issue and that they should capture all of that work (integration, deployment, etc.) in their DoD. However, this makes the line from the Scrum Guide in the thread's title sound a little conditional.

Also, would an Increment which is inspected by such a (weak) DoD still be a concrete stepping stone toward the Product Goal? If it is not releasable and if the value of it cannot be validated with the users/marketplace. 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.