We have one scrum team (distributed Agile) working on one code base. Due to parts of the team being in different time zones we wanted to divide the one team into two scrum teams. Our model with one scrum team was:

  1. Create a user story (feature) branch from the develop branch.
  2. After testing, merge back the user story branch to the develop branch at the end of the sprint.
  3. In the following sprint, perform the QA test with the integration build to verify there is no collateral damage with the new code.
  4. It depends on the product owner when to release to the field (we create a release branch when we are ready to release).

Now with the two teams, how can this be handled? Regarding point 3, when QA starts integration testing, how will we know which team's code has caused damage?

  • I don't understand the question. It's is normal to work via feature branches and merge them into develop when ready (via PullRequest). This does not matter if there is only 1 team (still multiple feature branches) or more teams (just even more feature branches). Just keep the feature branches up to date by pulling in develop when needed.
    – RvdK
    Commented Jul 10, 2019 at 22:45
  • With scrum anything is possible but this does not sound like a good idea. Cohesion in product management in the broader sense will suffer further, co-ordination will suffer, quality is likely to plummet, people will likely start to look for different opportunities. In the short run you may push a feature or two more per sprint period. You may need extra build and test servers to have the daily/nightly build ready when people get in, which will be twice a day. Technically it will be hard for any one team to commit to anything because neither is in control of the product. Good luck with that. Commented Jul 11, 2019 at 5:18
  • Thank you both. i edited the question by adding point C.
    – Scrum adv
    Commented Jul 11, 2019 at 9:27
  • The source of any damage will become clear when you analyze the problem and get to the code part you have to change to fix it. Version control's history will tell where it came from. But why would you want to know in the context of an integration test? Commented Jul 11, 2019 at 20:48
  • @MartinMaat - I mentioned integration testing because the QA integration team will be testing all the user stories(both the teams)of sprint 1 in sprint 2. In sprint 1 the developers do their own User story testing(before merging to dev branch) with the test cases they have developed
    – Scrum adv
    Commented Jul 12, 2019 at 14:53

2 Answers 2


Generally, I think the development branch with feature branches tends to work well and scale decently, but I have some concerns that the process you describe is introducing some risk that can be avoided.

First, work should be merged more frequently than once at the end of the Sprint. Maybe for some extremely complex work that is difficult to decompose into smaller, deliverable entities, it can happen from time to time. It may also be more likely in shorter Sprints that the work is done later in the Sprint.

Second, all of the testing should be done within the context of a Sprint. In Scrum, a Sprint results in a potentially releasable product increment. However, in your current state, it takes you two Sprints to have a potentially releasable product increment. In a few environments, independent quality assurance is needed, but in that case, I would recommend rethinking your value stream and Definition of Done to align with how the work actually happens.

Overall, it seems like you don't have a lot of test automation. I would want to increase test automation to reduce the time it takes to get feedback. And this is at all levels, from unit tests on particular methods or classes to automated acceptance tests that simulate human interaction with your application. If you can run these on a regular basis, you can get feedback on if a change introduces a problem before you merge it into the development branch.

Finally, I don't think your ultimate question of determining which team's code "caused damage" is necessary to ask. This is a side effect of having long feedback loops, instead of short feedback loops. And even so, the team that introduced the problem doesn't matter - in a scaled instance, all teams are responsible for the quality of the product. If an issue is found, let the teams pull it into their work based on their understanding of the problem and confidence in fixing it.

  • Unfortunately, QA can only work when development is "done" (by whatever definition), so the described process of testing before merge (presumable automated, because QA is not mentioned), and then integration testing by QA is sound. In fact, the most common method for moving work packages through different disciplines towards a release is for each discipline team to interleave their sprint with the other teams. Design teams tend to be a few sprints ahead, QA teams behind development. Commented Jul 11, 2019 at 10:34
  • Shortening the cycle is largely an illusion - not a useless one, though. In practice it tends to mean that developers write code during the start of a sprint, and focus on bug-fixing and preparing the next sprint towards the end. It helps in maintaining a hard DoD == releasable mapping, but actually softens up the subdivision of work packages into sprint sized chunks by requiring the introduction of buffer time for QA-triggered bugfixing. The result is better on paper, but requires more out-of-process organization skills from developers. Commented Jul 11, 2019 at 10:36
  • @JensFinkhaeuser Outside of highly regulated industries, that's not a true statement about quality assurance. And even then, independence is only needed for systems of a certain criticality.
    – Thomas Owens
    Commented Jul 11, 2019 at 10:37
  • I'd recommend a cross-team Kanban board to help visualize this. Basically, design team's "done" column becomes the product backlog for the development team, and development's "done" column becomes the product backlog for the QA team. If a downstream team needs more from the upstream team, it moves back into the product backlog for the upstream team at high priority. Commented Jul 11, 2019 at 10:39
  • I understand that in software, often enough it's not practiced. But the whole point of business process management is to illustrate these hidden dependencies and make them explicit (plus remove obstacles you identify). Most teams that fail at scrum-style self-organization that have consulted with me simply failed to identify how a work package "flows" through their teams, largely because of an overemphasis on the wrong end of a process, such as getting a work package release ready at the end of a single sprint. Commented Jul 11, 2019 at 10:47

It is common to have many teams working on the same code branches. this just requires keeping the feature branches up to date with the develop branch. The can be done with regular upstream merges.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.