Story points battle: Why & How

This article is not for the beginners want to learn the basic of Story points and related Poker bidding technique. If you are familiar with such stuffs but struggling to get the deep meaning of it and facing difficulties to implement it in real life – this article is just for you.

Being an Agile practitioner and working with the team to introduce Scrum in the company from scratch, this is how I see the challenges with Story points:

  • Most of the beginners tend to estimate Story points considering the one-dimensional unit “Hour”; try to convert Story point to Hour or Hour to Story point. We are familiar with hour based estimation and find it easy to think. But “Size” of a User-story/Requirement is not just the hour.
  • It is evident that different user-stories with same story point are taking different time length (in hour). It also varies with different teams.

 Wondering why is such?

  • Guesstimating a requirement is inherently a chaotic process, varies requirement to requirement and project to project and people to people. A requirement is definitely NOT one dimensional and depends on lot of internal and external factors (people, environment, customer, skills, experiences, domain knowledge, technologies, dependencies, unknown risks, management…you name it). Moreover, requirement evolves with time, knowledge and context. Such a complex “thing” you cannot easily estimate just by one dimensional “Hour”.
  • Requirement cannot also be estimated considering the LOC or number of features or number of input/output forms [It is an old issue and Google will provide you lot of materials in support of this idea]

To me it is our “feelings” that helps us to understand the size of a piece of requirement in our mind thru a complex biological procedure that we cannot depict mathematically. But we still can “feel” it – which is good to start with. Can you define feelings by some specific unit?

So to me, unit-less Story point is a natural selection to capture the “feelings” about a requirement during inception – when lot of factors are unknown. It is calculated as ratio, as the relative values with each other. If you know what it takes (effort, procedures, complexity etc.) to cook a “chicken”, then most probably you can “feel” what it will take to cook “beef” or “fish” and can compare their respective efforts. Numerically, if “cooking a chicken” is 5, then what do you think “cooking a fish” will be?

Some people may say 8, some may say 3 – actually both are correct in a sense those are just “feelings” based on behind-the-scene calculation (past experiences, domain knowledge & skills, personal point of view & context and so on…). That’s why during the Poker bidding, all member should discuss all the available information to come to a consensus.

More Problems from my personal experiences:

  1. People cannot see the real advantages of estimating story points straight in front of their eyes
  2. Not every Scrum member is aware of the goals & objectives of Story points
  3. and most importantly, some times we made the poker bidding session boring and worthless because of the very immature user stories from PO/Client (team gets tired trying to estimate the size of a black hole they have never seen!)

What happened in my case was unfortunate 😦 PO stopped the poker bidding – no more story points. Let’s get straight to the detail estimation of the SBL items in hours and concentrate on the short term sprint goals. Seemingly team is also happy by avoiding the long tiring poker bidding session.

Being a Scrum master, I was not that convinced but I also agree with the situation. After doing some homework, I proposed a model to resolve the three issues mentioned above. To my surprise, my proposal was approved and all are convinced now we should continue the Story points, Cheers! 🙂

I set the specific tangible goals for capturing story points to address issue #1 & 2 above, which is something like:

We will calculate the total story points per sprint per team and respective SM will preserve that data for future analysis that includes but not limited to: Team’s performance and improvement trends, team’s actual capacity, organizational factor to convert story point to time & budget etc. [specially measuring the team’s performance improvement is a key factor for understanding if we are doing Scrum/Agile correctly and all bought in the concept]

I came up with a new idea to avoid long bidding session as well as bidding on immature stories (issue # 3). I propose the following scenario:

PO presents the detail PBLs to the team. Team comes back to the workstation for self-study and realization what PO just told (we practiced it this way). Before going to the tasks breakdown (SBLs) and estimation session (after less than an hour or so), SM will send a web link where each member will fill up the number/point against each story and submit the form. The web form looks like this:

pokerbidding

I have created this form using Google-Form (easy and free :)) and the submitted data automatically stored in a Google-Spreadsheet like below (no coding :))

pokerbidding_data

As team gets this form when they are “sufficiently” knowledgeable on the requirements and no chance for face-to-face unnecessary discussion (we are not writing the bible), the whole Poker bidding takes less than 5 minutes! SM will take the bidding summary to the planning session and quickly discuss with the team to resolve only the conflicting PBLs (reality shows very few at this point of time – good news :)) and then count the total Story Points. SM will preserve this data per sprint for future usages as stated by the objectives.

Tips:
Each team needs to find one starting value (baseline) for a feature that every member can conveniently understand. Each member of the team will compare this baseline value to determine the story points of all the new PBLs. For best result, one team should use the same baseline for all of their sprints.

I also introduced a new concept that I call “Actual Bidding”:

After the sprint is completed, SM will again send the bidding form, before the retrospective session (or any other suitable time), to be filled up by each member based on actual experiences. Again it will take less than 5 minutes. SM will analyze/compare the data from both the bidding and feed the team to improve their bidding skills. 

Long live the Story Points and Poker bidding 🙂

Advertisements

4 Responses

  1. I plan estimation as being my next blog entry actually. Interesting how you put it about feelings… kind of like the Jedi in Star Wars 🙂

    • Great, waiting to read your Estimation in Scrum experiences.

  2. Are you not missing the point about estimate as team and not individuals? Thus not facilitating the so-needed communication about the difference in estimates in order to move the team to higher performance levels…

    • Hi Rune, thanks for expressing your concern.

      Actually it is other way around, we are reducing the time of Poker bidding session and utilize that time in the planning & estimation session where team altogether breaks down the tasks (SBLs) in half-day or full-day size and commits to a short term sprint goal.

      The purpose of the Story point is long term and only the “show your card now” is replaced by the quick online form – no other changes. In both the cases, it’s the individual bidding. Moreover, we introduced the second “actual bidding” to compare, learn & improve the team’s performance.

      Hope it clarifies the confusion.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: