When a project is big enough to have two or more teams working on the same project, we recommend that each team have its own backlog of User Stories and each team size its own stories with Story Points. Of course, this inevitably raises the idea of having each team conform to some “story point standard” so that project progress and team progress can be tracked "uniformly." Doing this more or less means that teams have to normalize story points across all the teams so that, for example, a 5-point story for one team is the same as a 5-point story for every other team on the project; an 8-point story is the same for every team, etc., etc., etc.

All I have to say to this idea is: “Ugggghhh… What a collosal waste of time!" I’ve seen teams try to do this and the effort put into trying to ensure uniformity of sizings across multiple teams is enormous.

I’m happy to report that there’s an easier way that still allows for overall project progress to be easily seen as well as individual team progress. In essence, instead of normalizing based on story points we suggest “normalizing” based on the calendar. Let me explain: let’s assume, for example, there are two teams on a project, each having its own backlog that has been sized with story points. Team A has 2000 story points on its backlog and Team B has 500. In this case you would have three burndown charts to track progress: one that’s combined (showing 2500 total points), a second one for just Team A (showing 2000 total points), and a third one for just Team B (showing just 500 points). In order to determine relative progress for Team A and Team B, you base it on the number of points completed vs. the number of iterations... Thus, if you're half-way through the project (e.g., 5 of 10 planned iterations are complete), you would expect Team A to be ~1000 points complete (50% of its total) and Team B to be ~250 points complete (50% of its total).

Where things get to be a little more complicated is when you have numerous teams working on a project (for some enterprise application projects we’ve worked with, we’ve seen over 40 teams working on the same project). With two teams, it’s fairly easy to bounce back and forth between Team A’s release burndown chart and Team B’s release burndown chart. When you have more than that, you can create a very simple chart (using any spreadsheet tool) that shows “percent calendar complete” and “percent story points complete” for each team. Following are two examples that we’ve used (they show the same data, just in different formats):

Figure 1

Figure 2

You’ll notice in the first chart that the schedule is 60% complete (the black bars) and then each team’s relative progress is shown. In the second chart, a stacked bar is used to show overall team progress. In this made-up example, Team 1 is slightly ahead, Team 5 is slightly behind, and the other teams are perhaps struggling...

I’m sure you can think of other, different ways of showing the data, so do whatever’s most helpful. The key is that this approach is so much easier and simpler than trying to normalize the sizing of story points across multiple teams.

Teams create processes to maintain repeatable results. Process is necessary. But when the process needs adjustment, teams often take the quick route and just add more and more to their process to address their new problems. The result is often process bloat, frustration, and project inefficiency. Then the team is back where it started.
Processes are typically built to get work done consistently and to increase efficiency and reliability. Improving a process however, can be time consuming and is more often avoided. So teams take short cuts. Here is an example that might sound familiar for a team that uses a process to checkin code. 1. Create unit tests to validate your code 2. Rebuild code with latest source code 3. Validate local build with unit test suite 4. Checkin new code and new tests.

The team discovers that some new code does not align with the design patterns that have been established so they add a rule to review all new code with the design leader. The team gets behind on updating older release versions with new code changes so they add another rule that requires that they follow the same rules for all the older release lines. Sooner than later the process to checkin code becomes so cumbersome that developers avoid it until the last possible moment.

Many of the best planned processes suffer this fate. But how do you avoid it? And what do you do if you see it coming? Agile has roots in kaizen, from the Japanese word for continuous improvement. In Mathew May’s book The Elegant Solution (167), he suggests that you should create a standard, follow it, and determine how to make it better. And then repeat that process. The standard provides the starting place but it should be adjusted to work better and to meet the changing needs of the demands. So having a process is good. Adjusting the process is good. Continuously improving the process is even better. But continuously adding steps to the process…? Not so good.

Here is one idea that I’ve found helpful: When you create a process, define measurable goals for the success of the process. For example, “We need a consistent process to checkin new code that takes no more than 10 minutes and enables 95% build success per iteration." If the team needs to add a code review to the process, then how can they manage it as part of the checkin process? Well, one team I know of faced this very situation and decided that they would spend 30 minutes every day at a particular time to do team code reviews. No matter what stage the code was in, the developers could get their code reviewed. While it still required time to do the reviews, that step was removed from their checkin process.

The key idea is to include a measurable goal for your process when you define it. Then stick with that goal when you change the process. Including a metric that defines process success requires that you look for ways to incorporate new requirements and continue to meet the metric goal. It may involve a little more work but it will ensure that the process continues to solve the problem without becoming the problem.

If you have any ideas on how to avoid process bloat please respond to this blog post and share your ideas!