DoD of Stories that need to be merges into multiple prod branches

The Definition of Done should capture all of the integration, testing, documentation etc. that is required for an increment to be immediately usable. That's the answer. Once an increment is Done, the imperative is to put it to use, so empirical feedback is obtained and the validated learning loop closed.

Scrum is very good at exposing organizational issues and shortcomings, many of which can be systemic. For example, you are experiencing constraints regarding CICD cycle time and branching and merging, which can take up to five weeks. That's what needs to be resolved. The problem is not with the DoD for exposing these issues, but you would have a problem if you adjusted the DoD to cover these issues up.

As @Ian mentions it would be worth checking CICD cycle time (if production deployment is a part of your definition of done). Also, I don't think deployment to production is a mandatory thing to mark a story as done (however some teams have that as a criteria). You could probably have UAT Approved/Regression tested as the last step in DoD (ensure customers perform the acceptance test/regression test within the sprint). Make sure to draft a definition of done with the whole team based on your situation and ensure it is understood and agreed upon by all. I have worked in a team where we had a 4-week sprint which includes 2-week development, 1-week UAT and 1-week regression testing and the sprints ends with a production deployment (done on weekends with some downtime). Once deployed to production, we close all the stories (so production deployment was a part of the DoD).

Done would mean the story meets the desired quality standards and is good enough to be delivered i.e. deployed to production and ready for users to use.

Thanks Ian and Anand for the input . I agree with the ideal approach, however the current reality here is that the CICD -branching and merging are with different department and they have their own way to do the quality check and those 3-4 production branches  has different timings. (ie each branch has different time to get into that production line ). And average cycle time for each of this branches to production is around 4 weeks due to the quality-check and other procedure .  That department is trying to improve the cycle time , however that is not going to fit into single week for 4 production branches.  So if we consider to keep the ticket to be in open state and simply wait for the  entire 4 different branches to be in production  , we need to wait for average 4 weeks ( 2 sprints )   and sprint backlog pilesup in un managed way after few sprints.

or  we can put my problem statement in this way-  what we can do if we have the story DoD  that has items which are not in the control of team( merging to 4 different production branches )

what we can do if we have the story DoD  that has items which are not in the control of team( merging to 4 different production branches )

What does the team think about this? -  It looks like the team is not sufficiently cross functional to deliver a Done increment.

Scrum is not prescriptive about the DoD the guide mentions The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

In your scenario, you have mentioned quality checks which means it is essentially a part of the DoD by the description above. So may be cutting corners on the DoD is not an option here.

Some questions to ponder upon are.

Why are there items not in control of the team in the DoD? 

Is a sprint duration of 2 weeks right in your scenario? 

Would increasing the sprint duration to 1 month ensure that you do all activities mentioned as a part of DoD?

Also should the scope (amount of stories) be decreased to accommodate the delay in the downstream process?

Thanks for the response, 

in automobile software world, thins are bit different from an  ideal open system.

Why are there items not in control of the team in the DoD? - Team develop things and merge to their local master branch and request the merge request to prod.  Rest of the merge process take place by other central team. The central team consolidate the entire merge requests from all the teams and merge to production. As I mentioned there are many prod branches as well.

That is the reason the production merge is not in the control of development team.

Is a sprint duration of 2 weeks right in your scenario? Would increasing the sprint duration to 1 month ensure that you do all activities mentioned as a part of DoD?

Increasing the sprint length is not going to solve the fundamental issue as the team pull more items or need to increase wait time. 

My problem statement is looking for the best practices that can adapt for the teams ( for certain extend  for the Components teams) , teams does not have any control on the story merge to production.  So what should be   best thing can to avoid   carry over the stories  sprint after sprint due to the production merge waiting.

Yes the basic issue is longer CICD cycle time and that is not going to be reduced to few days or in few hours in near future like in the open systems. Automoabile world  the CICD cycle time  reduction or reality is not like the way we have in other domain such as web development or app development.  

This is from the Scrum Guide section where the Definition of Done commitment is defined.

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.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of 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.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

So, does your organization have a global Definition of Done or does each team have their own? 

If each team has their own, then why not have the Definition of Done state that the work is ready for integration?  That way when the developers feel that they have delivered the requested functionality to the best of their ability, they can say they are "done" with that work.  That will allow other teams to start using the work that is "done" in their own branches if they need to.  It will also allow the team creating the "done" increment to move on the next work that is needed. 

If there is an organizational level Definition of Done, all of the teams should get together to work out wording that will allow them to progress on their work and be sufficient for communicating that their work is "done" based upon the current information.  That will allow that group that does the final merging and testing to know what is ready for them to use.  They become a stakeholder to the other teams. I will also suggest that "done" does not mean "in production".  "Done" means that the team doing the work has met all of the requirements that they can in order to create an usable increment of value. What you seem to have is a Definition of Delivery.  Or at the very least a the beginnings of a Definition of Done for the team doing the final production update. 

Great recommendations above! Considering your 5-week integration cycle,, either reorganise so teams can integrate their own work (a challenging long-term solution and see the Nexus Guide) or adapt to the current process.

Per the Scrum Guide, PBIs selected for a sprint should be completable within that sprint—refine and split integration tasks accordingly, e.g., into separate PB items.

Personally  I agree with @Daniel's suggestion, the DoD, should apply up to the point where the team hands over to the integration team. Treat the item as 'done' from the team's perspective once it's integrated into the local Master branch and handed over for external integration.