Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Integration of Increments

Last post 10:26 pm November 15, 2018 by Daniel Wilhite
9 replies
06:21 am August 19, 2013

Hi,

When many Scrum teams are working on the same product, should all of their increments be integrated every Sprint?

Thanks.


07:41 am August 19, 2013

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


08:51 am August 19, 2013

Thank you Michael. I appreciate your explanation.


10:31 am August 19, 2013

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.


09:21 am September 8, 2013

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


02:47 pm October 19, 2017

So as per the comments.

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

Am I right?

Thanks.


05:54 am March 1, 2018

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


05:54 pm March 1, 2018

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.


03:33 pm November 15, 2018

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?
 


10:26 pm November 15, 2018

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?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.