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

PDCA & SCRUM (or Agile); Why is it important?

The PDCA (Plan DO Check Act) cycle was made popular by Dr. W. Edwards Deming. This is a scientific cyclic process which can be used to improve the process (or product). This is cyclic in nature and usually time boxed. Plan  This is the first stage of the process. During this step the team discusses the objectives, the process and the clear conditions of exit (conditions of acceptance). This stage sets the measurable and achievable goals for the team. DO Team works together to achieve the objective set in the planning phase. Team works with the set of agreed process. Check Once the implantation is done team regroups and verifies the output and compares it to the agreed conditions of acceptance decided during the planning phase. The deviation, if any, is noted down. ACT If any deviation in planned tasks is observed during the Check stage, a root cause analysis is conducted. Team brainstorms and identifies the changes required to prevent such deviations in future. Team also

Why is potentially shippable product quality important

Agile teams work in iterations. During this period, they are supposed to work on product increments which can be “delivered” at the end of iteration. But how you know that the correct product was delivered? Many teams have different kinds of acceptance criteria and Definition of Done (DoD). But in many cases, this “done” is not the real “done” there might be some testing pending, some integration or review pending or anything else which prevents the actual use of the product increment. Many of these teams will need additional iterations to finish hardening their products. Many teams will implement different types of “gates” or approval steps to move to next stage. The free flow of product will be interrupted. They might end up doing mini waterfall within their agile process. Many don’t even realize this. This results in poor quality and requires additional effort to “harden” the product. Potentially Shippable Product increment The acceptance criteria and DoD should be modified

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