Current status:
We have the term of (service owner), where all microservices distributed among developers, and each service has a developer as (service owner). In the sprint, each developer is working on his microservice(s). Hence, we have smaller chunks of development streams run in parallel. Although we tried to add what so-called (back up service owner), more often than not, only the service owner ends up working on his microservices.

I have the feeling this is not scrum, as we lack the concept of team. However, it is also challenging to bring the entire team to work on one microservice at the same time (maybe if more than 2 developers, it will get crowded).

We are a team of 10. 5 core developers (service owners), and the other 5 from external vendor but they are part of the same scrum team. The external developers rely heavily on the internal ones in terms of specifications, code review, etc.

My question, how to organize scrum team around microservices?

  • What is the risk, though? Are you worried about turnover and people being underpracticed in other µServices? Do you have a capitalization deadline in a couple months, which demands maximum productivity by people doing waht theya re best at doing? Is this the time to cross-train? Sep 7, 2018 at 12:54
  • 1
    @NewAlexandria, Bus factor is one of the main concerns. Others include projects get blocked due one staff not available or on holiday, workload not evenly distributed result from some microservices grow more complex and demanding than others; just to name few
    – Hawk
    Sep 8, 2018 at 1:18
  • Your microservices might be too small. Do you have changes that spans across services? You may find out that the bounded contexts don't actually match network boundaries. You may be able to group the thing into let's say 2 or 3 sub contexts consisting of few services and this way start the process of sharing the responsibility. One day I found out that a product I was working on and trying to divide it was a small service at organisation scale. Make right-sized services. Oct 9, 2018 at 20:21

3 Answers 3


Having worked in a similar environment and also having faced similar problems I would suggest the following:

No single person owns any of the microservices. All of the servies are owned by the TEAM

This will be hard, since people have vested interest in only developing "their" services, but it is pretty much the only way to start transforming your group of people to anything that resembles an actual team.

You have to figure out a way (perhaps through incentives) for people to work on other services in the team as well. Until then you really do have several different work streams that are grouped together in a "team" for convenience.

After your people are working as a team you can start applying prioritization to team's work etc.


I agree with YoMan.

A good Scrum Master should be able to help out with this as this is not was intended with Scrum. The team should work together.

One of the first things that I would do is I would create a matrix of all the Microservices the team owns and each individual on the team and challenge the team to complete the matrix i.e. each individual must at some point work on every micro service.

I would also have a pair programming matrix so that every team member pairs with every other developer at least once every sprint or every release.

Is the full 10 person team co-located? If not I would setup a large screen and permanent video link between the 2 locations with a big mute/unmute button to allow them to comm.


Please use (any books on Scrum) to help your team understand they are not really a Scrum team. Scrum team works together and sign up to Sprint goal. In-fact good scrum teams do not differentiate between developers and Qa teams, everyone is an engineer.

Agile Alliance online reference states "The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional."

With a team where people only work on service they own, team is diluting a core principles of cross functional and self-organizing team.

To help drive this mindset, perhaps a good scrum master can cause team to be more self-organizing.

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.