Skip to main content

Leveraging scrum for large projects (not large teams); number of scrum teams’ vs. team size

The idea of working in iterations producing potentially shippable software is very powerful. Scrum has some very simple rules to help achieve this. Scrum advocates that team size should be 7 (+/- 2). This works most of cases; almost all the software’s can be developed by teams of this size.

One + One = Two Scrum Team = One Big product team

What if I have to increase the team size? My project is complex and I need at least 12 people to deliver the product. Now this becomes interesting. In some cases I have seen such one big scrum team. Historical data has shown that productivity decreases as the team size increase from the optimum number of 7.

So what should I do?

Split the team into two.

On what basis can I split the team?

You can divide the teams into feature, service or subsystem teams; empower these teams to do their jobs. There could be some additional attributes to PBI to identify this linking. Team can work on such PBI from the common PBI list. So there could be teams working on one single area of the product exclusively. But ensure that they don’t become silos. There should be frequent communication, discussions or meetings with the other team.

What about the Scrum Master & Product Owner?

It’s good if the teams have separate scrum masters & Product owners. But the since the teams are working on the same product; the same scrum master & product owner for the two teams will work. If you have separate scrum masters and product owners; ensure that you have a periodic scrum of scrum for scrum masters and product owners. Scrum masters should work together to remove the impediments. The product owners should work together to groom the product backlog

Can I add more teams?

If your product is more complex, you can add more teams to scale up. But there are certain preconditions for these. As the number of teams increase there will be the need of better communication, coding standards, technical reviews, shared builds, code & document versioning, better application servers etc. For any team to succeed such pre conditions or non-functional requirements are very critical. These non-functional requirements should be given more priority than the function requirements. Tomorrow if you are going to start a project which requires 300 people; according to scrum you will need around 42 teams!!! Imagine the type of noise this number of teams can produce if the proper infrastructure is not set up beforehand. Initially you should start with one or two teams only. This team can work on the non-functional requirements like setting up servers, database, build etc. Ensure that some small function requirement is also done in the initial sprints so as to demonstrate the functionality of non-functional PBI’s. For example if you are setting up Continuous integration & nightly build in the first sprint; you can add a small functionality like creation of login page to the sprint. The sprint demo will be a success if the build can install the application and shows the functionality of the login page thus effectively verifying the build tasks.

How will I coordinate the work?

You can start some of the meetings like

Daily scrum of scrums – to discuss the impediments and risks. This is a scrum meeting where the team members ( or scrum masters of the respective team members )

Tech review meeting between the different team’s tech leads or team members. Based on the requirement you can decide on the schedule. These meeting can occur before every sprint to discuss the technical challenges faced by the teams & share the best technical practices.

Scrum of scrum for product owners to groom the backlog

Release plan review - the product management team should meet periodically to review the status of the product development & delivery. These discussions can be centered on the release Burndown.

Which product backlog to use? A common product backlog or different backlogs for different teams?

This is a very tricky question. I will list down few scenarios which I am aware of. Experiment and find the best method which works for you.

1. Common main backlog and sub-backlogs for each individual team

there will be a common product backlog, the master backlog of the product. Teams can create the sub PBI’s from the main product story and develop the story further. Each team can individually give story points to their PBI. The mother PBI’s story point will be the sum of all the child story points. If any parent story is dropped all the child stories will be dropped.

A hierarchy of product owners working together and slicing the main backlog

If a new main story is added & prioritized all the sub teams (or the teams required) will start working on the new story. The initial break-up of the story will be done by the product owners of the respective teams. After the initial breakup the product owner, the feature development team (& customers) further develops the story, adding the missing links, estimating etc. Each team will have an idea of their velocity. The team will continue adding the stories from the main backlog until their capacity for the release is used fully. There will be a lot of churn as the development goes on. It will be responsibility of the product owners and scrum masters to ensure that the team backlog reflects the actual priority of the main product backlog. In many cases teams will have to plan their stories based on the delivery of the dependent stories from other teams. Such a separation ensures that the team works on the stories which they have developed.

2. Separate backlog for each team; no centralized backlog

This can be implemented for small projects but for very large projects such an arrangement can be disaster. Product owners will have to ensure that each backlog reflects the priority of the customer. Such an arrangement needs a very extensive communication plan between the product owners, teams & customers.

3. One centralized backlog with PBI in different sprints

This is an ideal case. Stories will be prioritized. Each team will pick they stories from the main backlog and develop it. It will very common for one team to work on the stories story pointed by other teams. Personally I don’t like this idea. This leads to a lot of confusion and last minute knowledge sharing. But in case you cannot avoid there are some good technical practices which can minimize the pain.

a. Ensure that you are following the XP practices like pair programming, Continues integration build, nightly build, Test Driver Development (TDD) & Behavior Driven Development (BDD).

b. Apart from the INVEST principles of user story ensure that you add the High Level Design & Low Level Design document to the stories. This will help a third person to understand the stories in a much better fashion.

If we have separate backlogs for different teams, who will add items (or select items) for each team.
Based on the team skill set or knowledge of tools/application feature area expertise, Product Owner should add items to each teams backlog. He is the right person to make this decision because he has the correct vision about the product & is responsible for prioritizing the backlog to generate the maximum ROI. Anyone (including the dev. manager, team) can suggest new features but final decision should be made by PO.

A better definition form scrum guide

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Ensuring the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.


Popular posts from this blog

SCRUM- Who should write a user story

Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation. In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can up

What are the rules of scrum?

A relatively new person to scrum asked me this question last day. My answer to that person was yes. But really does the scrum have any rules? Scrum is a framework which helps us in developing software. It has very few rules and apart from those basic rules rest of them are guidelines like best practices. Some of the rules  The roles of Scrum • Scrum Master - • Product Owner • Feature Team The PDCA cycle (  )  frequent communication about risks (daily) • Plan – Sprint planning • Do – Actual engineering sprint – deliver a potential shippable code • Check – Sprint review • Act – Retrospective  The scrum guide @ will be a good guideline for teams/companies planning to start scrum. If you are following the recommendation in these then you are following scrum. Apart from these rest of

Product Backlog: Should you write everything in user story format?

I like user stories a lot. They help everyone talk the same language and results in a better product. User story alone does not constitute product requirement. User story is supposed to be a place holder for discussion which should happen between the team, Product Owner and the customer. This discussion result in a common understanding which along with the user story content is the product requirement. This format captures the essence of requirement without confusing the readers User Story is only one of the many different ways in which requirements can be represented. This is not mandatory in any Agile “process”. But many have made this mandatory. I have seen many spending countless hours trying to write the requirements in user story format when they could have easily written that in simple one-line sentence in few minutes.   I have seen team members refusing to even discuss the requirement until product owner rewrote the requirement in user story format. Once I