Estimation model

Hello Sanjay.

The complexitylevel is always the same. Our coach Dominik told as a nice picture for it.

If your project is, to move stones from place A to B than the scores are the weight of the stones.

So some people will be slower, some people can lift 2 stones some can lift 4 stones, but it does not change the "complexitylevel" (weight of the stone). When the first person can push 2 stones and the second person only can push one of the sameweight stones, the two stones are not less heavy.
You also will get stronger because you are trained by pushing around stones, and will be able to carry more stones after the project has been running a few months. But the weight of the stones does not change.

The complexity is a relation between PBIs so you ma keep a wall where you save "perfectly estimated" PBIs for every complexity level, so the developers have something they can orientate on, during estimating.

Br.
Philipp

Another way of doing this is to use relative sizing. For this you need to arrange a session with the team to establish a sizing baseline. Here's how you can do it:

1) The development team gather round a large table.
2) The PBI's (ideally as index cards) are put on the table as a stack. They don't have to be in any particular order.
3) The facilitator takes the first PBI off the stack and puts it in the middle of the table
4) The next PBI is taken off the stack by the facilitator and given to the team
5) The team decide amongst themselves if it is larger or smaller than the first PBI. If it is smaller then it is put to the left of ithe first, if it is larger it is put to the right.
6) The next PBI is taken off the stack and put in the appropriate position by the team...left, right or possibly in between
7) Rinse and repeat. PBI's of the same size can be put above each other.

When all the PBI's are done, you have a spread of cards against which points can be mapped. Mid-range ones would typically be an 8, 10 or 13.

This gives you a baseline which the team can use in the future (e.g. in planning poker). As you can see, the numbers don't mean anything in and of themselves. They really are just relative.

@Sanjay

If your "points" just represent time, why have the abstraction? You're estimating duration rather than calculating duration which is no different than traditional estimates.

Points that are agnostic of duration allow you to calculate a range of forecasts as new situations arise around the team. As the team/product dynamic changes that influence sprint output, you can use the points to update forecasts. When you estimate the forecast directly, well... you have to fully re-estimate.

Now, the person who coined the term Story Points no longer recommends them. He recommends estimating in team weeks, but he also says don't forecast more than 2 sprints out (. Anything longer is to long to predict.

In either case, you need to be able to re-forecast OFTEN by not estimating duration too far out. You can have that by calculating duration from just-in-time output/velocity ranges or just don't forecast too far out.

I'm always very wary about trying to get too scientific with Story Points, and I certainly don't think that they should be considered some placeholder for actual duration/time or even complexity.

In terms of establishing a scale, this is what I usually coach:
http://scrumcrazy.wordpress.com/2011/03/11/whats-a-good-way-to-get-star…

In terms of trying to understand that story points are not complexity points, here is a good article on that:
http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

This comment also concerns me:

I noticed a couple of times team members looking at their peer's card before showing up their own

This sounds like the team is doing planning poker incorrectly. One of the main features of planning poker is that it helps avoid anchoring. Team members should not be letting other team members see their chosen card -- much like real life poker...

Charles Bradley

After noticing that team is cheating themselves they came out with an online tool www.planningpoker.com which allows you to estimate independently w/o getting influenced by peers. Also since ours is a distributed team it was more beneficial for us as compared to people speaking out their numbers on phone line or sending them on IM

The other thing we are looking for is to integrate the planningpoker.com with TFS. Or is there any other online tool available which can be integrated with TFS w/o any update required on server side?

Hi Sanjay,

Why would you want to integrate planningpoker.com with TFS?

Hello Josh

As our backlog repository is TFS and while using planningpoker.com we have to manually enter the PBIs/Bugs from TFS into planningpoker.com so it would be better if it automatically picks up everything from the TFS

Regards
Sanjay

Hi,
this blog outlines a neat method using the export to excel feature.
http://tommynorman.blogspot.co.uk/2013/01/distributed-planning-poker-an…

After the discussion, the planning poker value can be quickly updated in tfs.

I have used this with teams I work with.
Cheers
Simon

Exactly this is what we did for our grooming meeting :-)