Story Points as Spiciness; Using RSP to Estimate Story Points

About collabnet

  2 comments for “Story Points as Spiciness; Using RSP to Estimate Story Points

  1. Victor Szalvay
    March 13, 2009 at 12:49 pm

    I love the spicy-ness analogy, Kane. Question for you on the RPS approach: I assume this is used on well decomposed stories only, right? Sometimes it is desirable to keep a story large for organizational purposes and when it is not a high priority yet.

    And normally I wouldn’t notice this sort of thing, but man that guy standing by the projector screen is mighty handsome! ;)

  2. Jason Lewis
    March 13, 2009 at 12:49 pm

    Almost every team I have coached has adopted RSP estimating…and been successful at developing schedules.

    Some helpful things…

    1) I have never found that lengthy (3+ minutes) detailed discussion matters…just enough to allow the business problem to be sized consistently. Velocity will correct as the team matures and falls into technical patterns. I have actually found that talking too much, especially on technology, leads to assumptions and less consistent estimates, especially with teams with wide experience gaps.

    2) Again try to vote quickly…as soon as everyone understands the problem throw. If the team throws a consistent size then move on. It may be helpful to set a rule such as optimism (or pessimism) wins…say someone throws a 2 and everyone else throws a 3…go with the 2 and move on. Just apply the rule consistently and velocity will correct. Do not over complicate the rule or process.

    3) If you have a wide spread (by more than 1 number)…spend more time understanding the problem. Open up the technical discussion and build consensus. Many times the story will be rewritten, split or spiked as a result. This is time is well spent discussing a problem story. This really focus the effort and eliminates future problems. This tends to disappear over time…

    4) Always have a safety throw…stories need to be testable, small enough to complete in an iteration, estimatable, etc. If the safety is thrown, pick the treatment (split, spike, or rewrite) and put the stories aside. Do not debate the story and waste time.

    5) The key to this method is a good benchmark to estimate from. I do not suggest the current application (or design) as the benchmark. In fact I encourage each person to create a personal mythical benchmark application to estimate from. As long as they size against the benchmark consistently and look at each problem uniquely, velocity will predict. Resist the desire to use information outside the benchmark. (This is unique information that can not be applied consistently, so it just causes problems…of course be pragmatic about the obvious).

    Remember estimating is flawed to start with, so spend as little time as possible on it and get to producing working software ASAP. Stay consistent and let velocity do the work.

    Oh yeah…good consistent story writing helps. As a coach I try to encourage the safety throw on interdependent stories or non-distinct outcomes.

    If this method is applied consistently and simply, with good story writing and if release activities are done continuously…teams will reach a state where delivery can be predicted +/- 1 iteration out 12 months or more.

Leave a Reply

Your email address will not be published. Required fields are marked *