How Scrum can help in delivering an increment in a non-software scenario which is potentially not releasable but still has a business value?

Is there a reason you feel that increment would be treated any differently? 

It sounds like it's delivering measurable value (even if it's not to the end user) and can be inspected. 

Tony Divel- Thanks for your feedback. Actually, I came across a specific scenario for a Transitions team in Business Process who are responsible for doing process assessment/mapping and creating TO-BE processes for process streamlining and process improvement. In terms of understanding the concept of potentially releasable increment, they mentioned that their Sprint deliverables are not always in usable or releasable form but it is more in the form of some documentation which will be used at a later point of time when the process assessment phase will be complete. They want to do the assessment phase in Sprints using Scrum framework as the requirement is evolving so that they can deliver value in an incremental fashion.

Ah I see. 

For that type of group since they're developing business process models their definition of done and what is considered release quality might be different from your traditional software development team. 

I used to perform business process documentation and it's very much a collaborative and iterative process. In Scrum, the Product Owner does not have to release the increment at the end of the Sprint...but it should be of release quality. The same could hold true for whether or not this team wants to publish their process models.

I think it comes down to them defining what certain artifacts and outcomes mean with attention to their context. 

Thanks Tony. I second you on this. They need to define their DOD in collaboration with the customer as to what these artifacts mean in terms of release quality so that increments in each Scrum are not misunderstood. 

I mean each Sprint and not each Scrum. Typo :) Thanks.

it is more in the form of some documentation which will be used at a later point of time when the process assessment phase will be complete. They want to do the assessment phase in Sprints using Scrum framework as the requirement is evolving so that they can deliver value in an incremental fashion.

That documentation sounds like a promissory note for the future release of value, rather than actual value which can be inspected and adapted empirically in a production context. An "assessment phase" implies a stage-gated approach in which value release is deferred.

Ian- You are correct. The documentation is like a promissory note for the future release as actual implementation will happen after assessment is complete. The team wants to do assessment phase in Sprints. Actual value will be realized when To-be process designs are implemented and delivered. 

Ian Mitchell- Any more thoughts please on such increment having deferred value release?

A Business Process Model can be a living artifact that will illicit the creation of Product Backlog Items.  I've worked on a cross functional team where we had the capability to maintain and evolve our 'as is' and 'to be' business process documentation as a refinement activity. 

Doing this allowed the team to implement different pieces of the 'to be' state into production while continuing to receive feedback and evolve the 'to be' state. 

If the Scrum Team must rely on an outside group for this documentation, do you think there is value for the Assessment Team and the Scrum Team to move in parallel vs a stage gated approach? 

Tony- I understand your point. Only thing is the inspection can actually happen with the living artifact when the to-be model (proposed product increment) is implemented and evolved on the basis of feedback in terms of KVAs. This takes us back to the original discussion that the business value, increment and DOD will be different for assessment team and the team actually implementing it. You are absolutely right that if Scrum team is relying on outside group for this documentation then there is no value for the Assessment team and Scrum Team to move in parallel. So, both these teams should be part of one Scrum team.

The thing that Ian is pointing out is that having a promissory kind of document, might actually have 0 value if on implementation is appears that the initial hypothesis has a different (or even no) outcome. So all the time spent on the document has gone to waste, as we now have to recreate the document to fit the actual value created by the release of the feature. Zooming in on the Scrum Values, this has little respect to both the Scrum Team and to the customer, as the Scrum Team is creating something that they might have to redo the work (which could have been prevented) and the customer is wasting his money. It is also not being very open about the actual state of the work, as we cannot really inspect and adapt to anything. I think you catch my drift on this. 

Correct.

Yes, Sander and Ian. I got this. Thanks.