I agree these are all relative measures and it’s especially hard if you have multiple teams working on completely different projects. And I would never compare the two. They would each have their own set of benchmarks and KPIs. But I have found that getting it down to the task level helps a lot.

Cheers!

Kevin Thompson, Ph.D., PMP, CSP
Senior Instructor and Consultant, cPrime
http://www.cprime.com/training

Relative points are no more “accurate” than absolute points, so relative points have no intrinsic advantage in this area. For that matter, the idea of fitting relative points to a numeric scale (a la Planning Poker) has always seemed like a “neither fish nor fowl” way of looking at the world. It isn’t meaningful to map “bigger” and “smaller” to a Fibonacci or other numeric sequence. At a pragmatic level, this seems to work well enough for many Scrum Teams for them to get the job done, but this is more a testimony to the crudeness of estimation that Scrum can tolerate than it is anything else.

My conclusion, from reading and observation, is that Teams can use relative or absolute sizing for Stories, and succeed. This tells me that the choice of one versus another has more to do with local preferences than anything else, and that’s fine. What matters is the ability to deliver.

As for arguing “tooth or nail” over 2 versus 3 days, that is much a facilitation issue as anything else. People can always find something to argue over. If a situation like this arises when I’m wearing my ScrumMaster hat, I say,

“The split is even between the two cases. Three people say two, and three say three. This means everyone agrees that the Story can be done in three days. Is there any objection to going with three days?”

I don’t recall any case where we couldn’t agree and move on, and the answer has always been good enough.

Tom – Like you, my Teams estimate with Planning Poker, which starts with the Fibonacci sequence. That has always worked well for us. Also like you (I guess I’m a lot like you…) the only use for cross-team aggregates I see is purely for internal planning, at a very rough level.

Mark – Notwithstanding the interesting digression into estimation techniques, I strongly support your main point: Any attempt to measure (or worse, incent according to) the productivity of different Teams is fraught with peril. It will destroy morale and lead people to game the system.

Kevin Thompson, Ph.D., PMP, CSP
Senior Instructor and Consultant, cPrime
http://www.cprime.com/training

To avoid the hang up over whether something is 1 or 2 days we play planning poker using the Fibonacci scale. This way it is easier for the team to decide whether something is 3 or 5 ideal days for example and after the conversation they will move one way or another.

When we look at the team we purely look at how many story points they can complete in a sprint. We don’t compare this across teams as I think this is dangerous, who is to say a team delivering 60 story points is any more or less productive than a team delivering 75. As has been said this will depend on the make up of the team and the work in hand.

We do however use these figures when performing release planning in conjunction with historic availability but this is only for planning and no other purpose.

Kevin I’m wondering if this is similar to what you do when you say “how much work can five teams do” If you do this however I guess the teams must all be working on the same project/product and have a similar skill set for the comparison to be true?

Cheers

Tom
http://theagilemindset.wordpress.com/