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.
Comments