Back to Forum

Better distribution of merging finished tasks

Last post 11:08 pm July 2, 2022 by Mario De Caerlé
4 replies
Mariam Chkonia
12:28 pm June 30, 2022

Have a quick question, I wonder if anyone of you had the experience on the given topic, anyways any ideas will be helpful, so there is the idea in the team to have our sprint start a week after other teams, with a purpose to escape busy merging period on stage by the end of the sprint, taking into consideration that there are two week sprints. I really have no such experience and dont know if this will help the situation so any thoughts about that?

thanks in advance :pray:

Daniel Wilhite
02:44 pm June 30, 2022

I am going to assume that the Developers on the team came up with this idea since it would impact them the most.  With that assumption, I don't understand why you would be hesitant to believe them.  They have proposed an idea that will make it easier for them to deliver the increment of value produced in the Sprint.  Why would the Scrum Master or Product Owner have a reason to question it? 

The tricky part will be how to deal with that extra week for the transition. I suggest that you plan a single 3 week Sprint and then switch back to your 2 week cycle.  In my experience that is easier to do than to plan a 1 week Sprint to get you offset from the other teams. 

Ian Mitchell
02:58 pm June 30, 2022

Can the Developers produce a fully integrated, Done, and immediately usable Increment each Sprint?

If they can't -- and have to "merge" their work with that of other teams first -- will their proposal help to ensure that the above actually happens?

Mariam Chkonia
05:09 am July 1, 2022

Daniel Wilhite No, No we are not hesitant about the suggestion, we were hesitant about the process how to do it and my suggestion was exactly the one you mentioned (three week sprint and then get back to two week sprint)

 

Ian Mitchell  yea actually thats not an increment per se, its a compliance team mostly with the BE developers so its service not a product, in any case thanks for your comment and I actually really think that we should try at least we will gain some experience :)

Mario De Caerlé
11:08 pm July 2, 2022

My advise would be: add merging to the DoD, do it immediately, organize work to minimize chances of merge problems, and keep all the teams that work on the same product on the same timelines. Having different Sprint start times just make it all so much more difficult.



If you have multiple teams working on the same product, have a look at Nexus (Scaled Professional Scrum) for inspiration.



Or you know, another idea is to switch to trunk based development?

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.