Scrum: How to be consistent about Team weighting

Occasionally I'll return to the theme of Agile/Scrum and cover more detailed HowTo's that hopefully will give you additional insight into applying Scrum to your development practices. This time I'll cover issues around Team weighting of Product Backlog items for a Sprint, and the challenges of keeping consistency in the weights themselves.

If you've kept up with my series on Agile/Scrum, you probably remember that I wrote at length about the weighting process used in Scrum. Rather than devise an estimated number of days for each item (as is done in the Waterfall model that we all know and love), Agile/Scrum encourages use of assigning weights on a scale to each item. The weight is simply a number which has a meaning relative to the other numbers on the scale. So a 2 is assumed to be an item twice as hard as a 1, an 8 is 4x as hard as a 2, and so on. The typical scale that is used is:

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, and Infinity (the latter is an innovation of my Team for humor-sake).

A 0 is typically a task which is essentially done and is expected to be no work. These tend to be pretty rare, but they can occur. For my teams, we had to drop the 1/2 point weight since our tracking application (TeamPlain) doesn't yet support decimal numbers as weights for items. But if you are using another system, or just plain old index cards, you surely can use 1/2 point weights.

When the Team meets to assign weights to backlog items, especially initially, it can be a challenge to decide what is a 3 or a 5 or an 8, for example. My 3 might be your 5 and someone else's 8. So one tactic I use as a ScrumMaster for new projects is to have everyone vote on their weights for a set of items we're looking at rather than each one. We then write down on the board the weights they applied to each item and compare. Very often there is a pattern of how low-high weights were distributed even if the numbers chosen were different. A discussion then ensues among the team members about the numbers. Very quickly a consensus builds about what numbers seem to make sense for each task and what a "3" means, or a "5".

Now, it's entirely possible that one team's "3" is another team's "5". But that is just fine. In my case, this has happened. A team that tends to assign more points to an item than another team often has a higher velocity overall but that doesn't mean that they get more work done - it's simply the rate at which their weighted points of work get done; since they have higher points to items, their velocity is higher.

However, afterwards, I ask the team to do 2 things. First, I ask them to review their numbers and see if something they marked as a "2" is really twice as large as something they marked as a "1". This continues through the set of items they've weighted. Sometimes it highlights that an item they weighted is out of synch with the weights for other items and they make an adjustment.

Once this is finished, we then review the weights and look at the scale. I don't typically like weights where the median seems to be hovering on the high side around 8 or 13. It doesn't provide enough granularity above that point since the larger numbers are assumed to handle more squishy, undefined tasks, not just bigger tasks. So if I see this happening, I will slide the numbers down a notch or two, and review with the team. This resets the scale so that they are using an 8 or 13 for a larger task although what is larger can be different team-to-team as I mentioned earlier.

This process has resulted in a much smoother initiation of team's into the Scrum practice of weighting items. We also end up with better consistency across Sprints since the team can double-check that their weights for new items are similiar to older tasks which were the same or similiar in nature. If a team assigns a "3" to the task of creating a form, for example, and a couple of sprints later assigns a similiar form creation task as a "5", I will probe to see why. Sometimes this happens because the team discovered that their initial "3" was too small to account for the typical work to create, test and document a form. Often it can be because the team forgot their earlier number and the new "5" is weighting slippage that is occurring.

Part of the role of the ScrumMaster is to watch for and correct these problems that can creep into a Sprint. But ultimately it's up to the team to internalize the effort of creating weights and what they mean to that team. It's a joy to step back from a planning process and see the team moving so quickly through the process of estimating that they are thinking out loud with each other, adjusting estimates based on discussions, and concluding the planning session with agreement around the set of items and number of weighted points. Even in our larger efforts, I'm seeing planning sessions drop from 3-4 hours to 1/2 an hour depending on how well constructed the Product Backlog is, and the preparation of the Product Owner(s).

But that is a topic for another post.

Posted by Mark M. Baker at 12:54 PM  Permalink