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

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.

 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?

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?

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?

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.

All clear. Thanks for sharing it ☺️

@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?

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. 

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.

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. 

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.