Skip to main content

Estimation model

Last post 11:34 am February 21, 2013 by Sanjay Saini
9 replies
12:32 am February 18, 2013


It's been a long time that our team was doing the poker card estimation w/o knowing what does a 2, 5, 8 etc.. mean. They learned during Scrum class that it is just a complexity level not the man days estimation. I noticed a couple of times team members looking at their peer's card before showing up their own. The complexity level differ for each resource, I know Scrum doesn't count on it but it still exists in real world. Team decided to come up with a common complexity model so that it is same for everyone irrespective of sprint duration, no of resources in the team etc.. Here is the model which we have just started using in our team, let's see how it goes. So when we say 20 it means half of the team is going to spend their full sprint effort on that PBI.

Do you guys have any suggestion for us?

Story Points Complexity Level
40 full team full sprint
20 half team full sprint
13 1/3 members of team full sprint
8 1 team member full sprint
5 1 team member half sprint
3 1 team member for 1/4 sprint
2 1 team member for 1/15 of sprint
1 1 team member for 1/50 sprint

Regards
Sanjay


03:33 am February 18, 2013

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


09:09 am February 18, 2013

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.


05:32 pm February 19, 2013

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


05:57 pm February 19, 2013

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


11:53 pm February 19, 2013

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?


10:09 am February 21, 2013

Hi Sanjay,

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


10:51 am February 21, 2013

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


11:23 am February 21, 2013

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


11:34 am February 21, 2013

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.