Forums

By posting to our forums you are agreeing to the Forum terms of use.
Estimation model
Last Post 21 Feb 2013 10:34 AM by Sanjay Saini. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Sanjay Saini
New Member
New Member
Posts:78
Sanjay Saini

--
17 Feb 2013 11:32 PM

    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
    Philipp Eisbacher
    New Member
    New Member
    Posts:32
    Philipp Eisbacher

    --
    18 Feb 2013 02:33 AM
    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
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    18 Feb 2013 08:09 AM
    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.
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    19 Feb 2013 04:32 PM
    @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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    19 Feb 2013 04:57 PM
    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/201...ry-points/

    In terms of trying to understand that story points are not complexity points, here is a good article on that:
    http://www.mountaingoatsoftware.com...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...
    Sanjay Saini
    New Member
    New Member
    Posts:78
    Sanjay Saini

    --
    19 Feb 2013 10:53 PM
    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?
    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    21 Feb 2013 09:09 AM
    Hi Sanjay,

    Why would you want to integrate planningpoker.com with TFS?
    Sanjay Saini
    New Member
    New Member
    Posts:78
    Sanjay Saini

    --
    21 Feb 2013 09:51 AM
    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
    Simon Reindl
    New Member
    New Member
    Posts:28
    Simon Reindl

    --
    21 Feb 2013 10:23 AM
    Hi,
    this blog outlines a neat method using the export to excel feature.
    http://tommynorman.blogspot.co.uk/2...d-tfs.html

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

    I have used this with teams I work with.
    Cheers
    Simon
    Sanjay Saini
    New Member
    New Member
    Posts:78
    Sanjay Saini

    --
    21 Feb 2013 10:34 AM
    Exactly this is what we did for our grooming meeting :-)
    You are not authorized to post a reply.


    Feedback