Integration of Increments

Yes they should.

Let's think about, if they don't:
- The state of the product is unclear (due to not yet discovered problems that will arise during integration and complete product increment tests)
- The PO does not have a clue whether the THING he/she was presented is potential shippable
- It is not transparent to the organization what the next reasonable steps are (if there difficulties due to integration, the next steps would be rather clear, but not integrated - its only wishful thinking)

All this sad, there are some occasions where integrating each sprints is futile:
- If the sprint is abnormally terminated by the PO
- If testing gear needed to verify a potential shippable product increment is not as available as it should -> clear impediment
- Integration environment is not accessible -> clear impediment
- Integration procedure is to complicated to do every sprint -> clear impediment, and yes pain is sometimes a good teacher
- The other teams are working on different products (I stress: not components of the same product) that are highly integrated into your team's work -> a nasty impediment

Don't take "too much effort", "too much time", "too high cost" easy, see it as an impediment and a leverage to act as a Scrum Master by taking responsibility in removing these impediments.

I hope, this answers your question.
Michael

Thank you Michael. I appreciate your explanation.

Each increment released by each Scrum team at the end of a Sprint must be potentially shippable. This implies that they must not only be integrated, but also subjected to whatever system integration, UAT, or pre-release testing is needed.

That's a tall order. There is controversy at the moment about the use of enterprise release frameworks (e.g. SAFe), which dilute this standard somewhat.

I would say the integration should happen multiple times during the sprint as and when required. We have eight teams working on the same product and we have multiple integration environments. Dev Int - where the integration happens twice a day, QA Int - where the integration happens twice in a week and UAT - where integration happens every sprint.

It doesn't mean we have to release all eight team's feature every sprint, we have a mechanism which allows us to release the selected feature every sprint, if required.

Cheers
Sanjay

So as per the comments.

It should be done as a good practice, but it is not mandatory.

Am I right?

Thanks.

I would think integration of increments is mandatory or else it becomes in eligible for release (which is against the potentially releasable increment definition). However the product owner considering the high effort & cost aspect of integrating every increment may still accept it as a partial work complete and add a line item in PB to track the integration and prioritize it before the sprint when it needs to be shipped.

If the impediment (ability to quickly integrate using an automated script or etc) can be resolved, I would add integration as part of DOD as a good practice so that it can be done during the sprint 

Thanks

Jagan

I would think integration of increments is mandatory or else it becomes in eligible for release (which is against the potentially releasable increment definition). However the product owner considering the high effort & cost aspect of integrating every increment may still accept it as a partial work complete and add a line item in PB to track the integration and prioritize it before the sprint when it needs to be shipped.

That line item would constitute technical debt. Technical debt should indeed be accounted for in the Product Backlog in order to provide transparency over the total amount of work which is thought to remain.

However, the Definition of Done represents the standard to which the Development Team holds itself in order to avoid incurring waste such as technical debt. No one, not even the Product Owner, can oblige a team to compromise on technical excellence irrespective of the cost which may be involved in attaining release standard. The team may simply do less work which does reach that standard, or they may do no work at all until the standard can be achieved. In a good implementation of Scrum, a Product Owner would not therefore be in a position to accept unintegrated work. A professional Development Team should always observe a standard of Done which yields integrated increments of release quality.

Additional question on the integration.

Q-1 ) Should integration be a task or a story in backlog. because if its a task/work then its a big thing because it adds lot of effort on the testing aspect post integration.

Q-2) How is integration withing sprints handled when its related to 2 or more scrum teams working on same product. 

And now both teams items are ready to be integrated. So does it become a story for a future sprint as integration?

 

Scrum does not specifically state anything on this on purpose.  However, Scrum also does not overrule common sense.  If you weren't doing Scrum and had multiple development teams working in the same code base, what would you do? 

As you can see, many of the Scrum practitioners fall back on the "potentially shippable increment".  It is because it covers common sense.  However, all organizations will have different interpretations of "potentially".  Most of the Scrum community will also coach the "integrate often" mantra because in the long run it is good code stewardship and reduces complexity in the end. 

I guess I'd like to flip your question back on you.  

When many Scrum teams are working on the same product, why wouldn't their increments be integrated every Sprint?