Story Points as Spicy-ness; 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].

Spicy-ness 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 spicy-ness as an analogy is that it’s immediately understood be 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 fully discussion so that the team has a shared understanding of what needs to be achieved and the best possible way to achieve it.


    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.


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


    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:


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. Spicy-ness) 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 fabonicci numbers [6]), and hence offers greater simplicity.
  3. It’s fast … very fast!

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.

Bookmark and Share

[4] Thai One On Restaurant review

About these ads

14 thoughts on “Story Points as Spicy-ness; Using RSP to estimate Story Points

  1. Hi Kane–
    Interesting approach. I teach a lot of classes on “Agile Estimating and Planning” and one criticism I hear of one of my techniques is that people think it’s voting and that wrong values will result if there are three new employees and the founding architect estimating. They feel as though the 3 new employees will outvote the architect, who clearly knows more about the item being estimated. I coach that in “Planning Poker” (the approach I advocate) the individual estimates are opinions not votes. They are discussed and then a re-“vote” happens. In this way the more experienced, senior opinion would be heard and possibly influence others. So, I’d recommend repeating the RSP until everyone agrees.

    Another tweak I’d make is to think of the fingers as powers of two and would include a “no fingers” option. With five fingers that would give estimates of 1, 2, 4, 8, 16, and 32.

  2. My friend (and ex-collegue) Jason Lewis also left some comments (February 22, 2006) that are worth repeating here:

    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.

  3. I do something what Kane’s describing for stories that are small enough to commit to Sprints. For larger items (epics that need to be broken down in the future) we just use 10, 20, 50, 100, etc. The point is not to dwell on it too much because estimates are intended to be imprecise.

    I prefer RPS because I want everyone to express their estimate before they’ve heard the others. The only way to do this with the Fibonacci sequence is to print up “planning poker” cards no one ever seems to have handy. Most of us have at least five fingers at any given time, which is great because estimation meetings are often unplanned, informal events.

  4. I’m not a developer, and relatively new to this, and work with developers who would like to change from estimating tasks in hours to story points. It escapes me–why there is an advantage in using story points over hours if those estimating consider complexity and volume when they estimate hours? It seems to be just a different term that has the same function, which then needs to be converted back to hours since we work and get paid based upon hours not story points. I understand people develop at different rates, but it seems that it you determine hours based on an “average” degree of complexity and volume (measure of repeated low-complexity tasks) and then adjust based on the skill of the assigned developer, there is no advantage. It seems there must be a reason since others have adopted, but I haven’t seen the compelling difference. My cynical side suggests this is a way to make management seem more complex than it really needs to be. Hoping someone out there can clarify this for me.

  5. Before addressing your question, there are a few points that I need to clarify.

    > work with developers who would like
    > to change from estimating tasks in
    > hours to story points.

    We only ever estimate User Stories in Story Points. If Tasks are estimated, then they are always estimated in the *number of hours remaining* so that the team can generate a Sprint Burndown Graph. Some teams prefer not to estimate tasks and will instead draw a Task Burndown graph, or simply use a physical Story board.

    >… it seems that it you determine hours … there is no advantage.

    I have personally used duration (in days) successfully. I would caution against using hours, because estimating software is simply not that precise.

    An alternative approach (and one which you may be more comfortable with) is to estimate in T-shirt sizes (e.g., XS, S, MM, L, XL). This tends to be more intuitive and avoids the whole concept of “Story Points” which I think is quite contrived.

    I would also recommend Mike Cohn’s book “Agile Estimating and Planning” (

    > … a way to make management seem more complex
    > than it really needs to be.

    Believe me when I say that Scrum makes software management much, much, much simpler. I have flash backs to a Gantt Chart (50 people for over 9 months) that was automatically re-leveled by MS Project.

  6. Kane, this may be the most helpful info–the vast majority of these tasks are feedbacks from users of our web-based reporting system, which the vast majority are very small–less than 10 hours, a few LOV changes as small as 30 minutes, and a few up to 40 hours. Dozens of these are dispositioned during each month long sprint–we only have 4 developers.
    We have no problem with scrum development overall, it seems to work well for us, just picking at this one point.

  7. Bruce,

    Regardless of the number and size of Stories, I would still encourage you to try using Story Points; even if it’s a simple scale such as T-shirt sizes. You can then use “Yesterdays Weather” (i.e., the amount of work that we can achieve this Sprint is about the same as the amount of work we achieved last Sprint) for capacity planning.

    You can also use Mike Cohns Alternative Release Burndown graph for release planning:

    > Dozens of these are dispositioned during each month long
    > sprint–we only have 4 developers.

    Have you and your team considered a shorter Sprint duration? A duration of two or three week would give the Sprint more definition and would allow you to have shorter review and planning meetings. Just a thought.

    Best regards,

  8. Kane, We currently use a sprint burndown graph that seems to work; we have tried 6 week sprints, and then came back to 4–seems to work for us. I think hours give us a reasonable estimate, and still haven’t heard an answer to the original question–why there is an advantage in using story points over hours if those estimating consider complexity and volume when they estimate hours? I could see it if the task is very large–in the hundreds of hours. But, you still come back to trying to fit them into a 40 hour work week–a subunit of a sprint.

  9. Bruce,

    In you’re scenario there may not be an advantage. The whole idea of using Story Points is that we (humans) are better at relative sizing than we are of absolute sizing. If your Stories are small enough to estimate with some degree of confidence, then perhaps you don’t need to use Story Points. You’ll just have to inspect-and-adapt.

    Best regards,

  10. it’s sortof interesting, if you look at their hands you can tell what they’re going to ‘bid’ while they’re still in a fist. :)

  11. One interesting question is how to you translate story points into actually hours of estimation? So if a story is 2 story points, how long does that take. In addition, since you may have only had a couple of hours of discussion and understanding, how can you be confident in that estimate? Is there a high fidelity estimate initially then later on a low fidelity estimate?

  12. Most Scrum and agile teams will not try and translate Story Points back to hours … and, I would argue, that’s bad practice. Story points are a measurement of relative sizing so really there is no direct relationship with time. In order to get a measure of how much the team can achieve in a Sprint, Scrum teams will apply the principle of Yesterdays Weather. Mike Cohn discusses Relatives Estimates in much greater detail in his book “Agile Estimating and Planning” which I would strongly recommend.

Comments are closed.