Most Done vs Should Done : multi sprint PBI

You seem to be in a pickle with this one, as the PBI will not make the increment for the first sprint, so will be moved back to the PB and hopefully re-evaluated before being selected for the second sprint.  The same thing happens for the second sprint, and then finally it meets the increments DoD in the third sprint (that's if you are running 3 or 4 week sprints).  

It seems to me that inspection and adaptation is not taking place, and by the sounds of it, the organisation is not fully on board with Scrum.  

I don't see how the customer not liking Kanban prevents your team from still using Kanban, as its up to the self-managing Scrum team to decide what tools and techniques they use, not the customer.  

I think the Scrum Master needs to be allowed to do their job in coaching and guiding the organisation, PO & Developers in regards to the Scrum framework

There is some bad choices in the system, we cannot change now.

Does anyone in the system expect outcomes to be improved?

Do you thinks it's OK to alway switch 40-70% of the PBI between sprint? It's OK to meet the DoD only after 2 or 3 sprints? 

No. The leap-of-faith people must take before seeing finished work is no longer one Sprint and the meaning and purpose of the event is lost. Now what?

What we have apply many time was to reducing the DOD by excluding the deployment in production.

Many scrum Teams wait few sprint before going in production. The PO choose the release time. But having a request to lunch the deployment processes mean a complete different DOD for at lease few days in a sprint. The analysis and development are already done and we have to test in production. The others PBI have to complete the development and wait in QA environment for a release date from the PO. Having to wait few days between sprints for deployment or having few teams member in observation is too strange (creative time is not needed currently).

We can also think about a team with many differents technologies, each one with a different elements for a DOD.

A DOD with a lot of exclusion is good idea? Having more than one DOD is Ok? Or adjusting the DOD can work?

A DOD with a lot of exclusion is good idea? Having more than one DOD is Ok? Or adjusting the DOD can work?

What do you actually hope to achieve by this?

I hope to consider the delivery activity only every 3 sprints in the DOD.

Do you think adjusting the DOD every 3 sprints is acceptable for the scrum framework? 

The Scrum Guide says that work cannot be considered part of an Increment unless it meets the Definition of Done, that in order to provide value the Increment must be usable, and that multiple Increments may be created within a Sprint.

How many Done, usable increments do you hope to create each Sprint?

What is the duration of your Sprints? Do you take into account known variables that may influence what duration suits your context?

Rule of thumb is that the shorter duration is better. However, if we assume that your PBIs are as "small" as it is reasonable, and DoD reflects what done means in your context, we are left in hand with time available for development. 

To address that limitation you may consider below things separately or mixed:

• Adding more developers to the scrum team, as long as it is still small enough to remain nimble and large enough to complete significant work within a Sprint.
• Reduce the batch of work undertaken during the Sprint, this most likely will impact also crafting of your Sprint Goal.
• Change the Sprint timebox so that at least one Done Increment will be created. Maybe shorter one will be easier to grasp, plan and undertake, or longer ones would address better complexity of your work. Sprint may be as short as one day, and as long as one month.

I am asking that, because based on my experience, people often sets sprint timebox artificially. For example they choose to have "common duration" of two weeks, and don't bother if it is right duration in their context, nor what they should consider when deciding that. 

Maybe, if you already accepting that creation of Done Increment lasts 2-3 sprints, you can address that by choosing that duration as your sprint timebox, and by that reduce the amount of events that may overwhelm, distracts and defocus you?

Usable increment is not possible every sprint in my team. Shippable increment otherwise is possible and the PO is happy with that. Deploying an increment take time in SAP with z and completing this work change the DOD. Sometimes everything can be completed in few days, but generally the PO prefere to wait few sprints. When we deliver, we still have have some PBI in development (generally shippable at the end of the sprint) but we have some work to do for delivering the PBI already done in previous sprint. The PO strategically choose on the done PIB what he want to see in production. 

Did you see a conflict in the DOD between the PBI of a usable increment and a shippable increment?

Presently, only one developer can work on a particular PBI, parallel work is impossible and pair programming is not advantageous. Changing the size of a teams of 6 developer cannot reduce the treatment time of a PBI. 

For the length of the sprint, we can separate the analyse, the development and the deployment in different sprints, but I'm not sure the PO  and the customer are going to be happy (shippable increment are not going to be possible). We develop or change different features in a sprint.