Story Points as Spiciness; Using RSP to Estimate Story Points

I’ve long struggled with the concept of Story Points and how to effectively communicate this to clients. It’s never been a natural concept for me, and most explanations of Story Points are half-baked. Explanations such as “Story Points are relative measure of complexity”; are quickly countered with “What about situations where something is not complicated by takes a long time to build?”

Most Agile practitioners end up trying to cover all bases by defining Story Points as some measure of both size and complexity [3].

Spiciness Analogy to Story Points
The analogy that I’ve personally come to favor is spicy-ness. Anyone who has eaten in an Thai restaurant will immediately understand that a 3 star item is a lot more spicy than a 1 star item, and that a 5 star item will likely cause physical pain. One of the benefits of using spiciness as an analogy is that it’s immediately understood by both senior management and the project team. I’ve even started to use the same dialog as my favorite Thai restaurant [4]: “How spicy would you like that Story?”

Using RSP to estimate Story Points
Rock-Scissors-Paper (RSP) is a simple children’s game that has a wide appeal [1], [2]. A concise definition of RPS can be found on the WorldRSP website [5]:

RPS is a decision making game of wits, speed, dexterity and strategy between players who are unable to reach a decision using other means. The result of a game is considered a binding agreement between the players. RPS is a game played by honourable people and therefore every effort should be made to commit to the outcome. The game is played by substituting the elements of: Rock, Paper and Scissors with standard hand signals.

When estimating Story Points using RSP the game is played in the same manner. The essential difference is that rather than throw a Rock, Scissors or Paper, the players throw a Story Point estimate indicated by the number of outstretched fingers.

One immediate disadvantage of using RSP for Story Point estimation is that it’s limited to the number of fingers on one hand (i.e. 0 to 5). In practice, however, this has never been a problem.

A Practical Example
To illustrate how RSP Story Point estimation is used, it’s best to consider a complete example.

    Step 1. It’s always important for the Customer to explain what the problem is. Part of the discussion should include Acceptance Criteria. That is, what does the team need to deliver so that the Customer is comfortable with saying that a Story is complete.

    Discussing the business problem and potential solutions can be a time consuming process. It’s important, however, to have a full discussion so that the team has a shared understanding of what needs to be achieved and the best possible way to achieve it.

     Story Points as Spiciness; Using RSP to Estimate Story Points

    Step 2.
    Having discussed the problems and some potential solutions, the team is read to begin estimating. Here we see that the team is already primed ready to play RSP.

     Story Points as Spiciness; Using RSP to Estimate Story Points

    Step 3. RSP has begun and the team is in action.

     Story Points as Spiciness; Using RSP to Estimate Story Points

    Step 4. The results of the RSP Estimation. The Story Point estimate is obtained by taking the most numerous estimate [in this case 4] as shown below:

     Story Points as Spiciness; Using RSP to Estimate Story Points


Advantages of using RSP Story Point Estimation

Story Point Estimation using RSP is a very rapid way for a group of people to determine a single order of magnitude estimate (ie. Spiciness) of a Story. This approach has some advantages over existing methods of Story Point Estimation. These are:

  1. In group activities it’s not uncommon for team members to defer judgment to the team “lead”. When using RSP estimation all participants reveal their estimates simultaneously, making it is difficult for an individual to use his position to influence the group.
  2. The range of options is conceptually very simple and limited to the range 0-5. There is not possibility having an exponential scale (or a scale based on fibonacci numbers [6]), and hence offers greater simplicity.
  3. It’s fast … very fast!

Summary
I’ve introduced the idea of using a variation of a simple children’s game to help speed up the process of estimating Story Points. This approach is limited to providing estimates in the range of 1 through 5. It is, however, very efficient and can be used to quickly coordinate a large group.

Finally, I’d like to thank my collegues Victor, Eric and Zoltan for their help and support.

References
[1] http://www.worldrps.com/
[2] http://www.rpschamps.com/
[3] http://www.mountaingoatsoftware.com/
pres/AEPScrumGatheringFall2005.pdf
[4] Thai One On Restaurant review
[5] http://www.worldrps.com/gbasics.html
[6] http://www.mountaingoatsoftware.com/
articles/aepsample.pdf

Download the PDF version: Story Points as Spiciness blog

Posted in Agile
2 comments on “Story Points as Spiciness; Using RSP to Estimate Story Points
  1. Victor Szalvay says:

    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 says:

    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 *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
sign up for emails
conversations

CollabNet: 2014 #FutureOSS Results Are In! Finds OSS Powering New Technologies, Reaching New People, & Creating New Economics http://t.co/ECtIkdjG9R
Date: 14 April 2014 | 5:05 pm

CollabNet: Certified #Scrum Product Owner (CSPO) Training Course at #CollabNet HQ in South San Francisco April 16-17 http://t.co/ETLXBrxtTr
Date: 10 April 2014 | 10:25 pm

CollabNet: #Agile CSM Course coming to NYC on April 14-15! Register today! http://t.co/xjYes5deXM
Date: 10 April 2014 | 4:30 pm