Question: Re - Estimating with Story Points

Dolores asks: Hi Joe – …I have always been taught that story points should never be compared to time measurements. However, we were using 1 story point = a day or a day and a half of work to estimate initial team velocity. One of the questions we often get about scrum is how do points relate to hours (or days). So, what’s the best answer we should give to our users who are new to scrum and trying to get their heads around story points? (seemed like a good blog topic to me)

Answer:

Let’s start even earlier.  First, Scrum is not trying to track inputs, but rather results or outputs.  We want to maximize the results.

Next: When the Doers in the Team are using story points to estimate stories, they should not be thinking of time.  You are correct.  Try to get them (despite prior experiences) to think simple ‘relatively’.  If the Reference Story is 1 SP, then how big is Story X?  And they use the Fibonacci cards to indicate the relative size.  2x the Reference Story, or 5x the RS, or 21x the RS.

A bit later, all of the Product Backlog (for the next x months, let’s say 6 months..some short period) estimated in story points.

Later still, we want to have a decent guess at when the top Y set of stories (eg, the first release) will be done.  And we have a brand new team that does not have a velocity.  In that case, we have to use that formula that we showed you.  And that formula includes a ratio: 1 Story Point = Z ideal person days.

You are right to be concerned.  Yes, we do not want the estimators (the Doers) to know that ratio when they are voting.  If they do, they tend to go back to the ‘old ways’ of estimating the time to do work (usually in ideal hours or days) and then converting that back to story points.  Not good.

BUT…you (let us say you, as the ScrumMaster), need that ratio to make a decent guess (now) at what the team velocity will be.  So, I recommend that you and an outside person look at the RS (Reference Story) and maybe a reasonable sample set of the Product Backlog, and determine the typical ratio (1 SP = X ideal person days).  Do not tell the estimators (Doers), but use that ratio in the calculated velocity.

Soon, this problem goes away (we hope) because you can use the real velocity after a few sprints, rather than the calculation.

Note: It is normally better if Z is in the range of 1 to 2 ideal person days.  I won’t explain why here, just trust me on this.  It helps some.

One further note.  As we also mentioned, once you know certain information (including the Team’s real velocity), you can start to infer a relationship between 1 SP and ‘real’ time.  At least for a given team.  This is fine for managers and others to do if there are no ‘bad behaviors’.  I do not recommend talking about this with the estimators.  The research shows that people estimate time badly.  But people are fairly good at estimating relative size/complexity compared to a Reference Story.

Everything clear now?

Aggressively Attach the Impediments

We can look at impediments or continuous improvement many ways.

For us, in Scrum, we usually look at impediments as continuous improvement for one [Scrum] team at a time.

Note: Of course, we can think of impediments also for a scaled group of teams or for the agile adoption, and for other kinds of things. Not for today, though.

I wanted to reiterate a few key points that I make in my course.

• Anything can be an impediment.

There are many types of impediments.  Blockers ( meaning an impediment that causes a full stop to one User story in the current sprint) are one type of impediment.  Usually we define impediments as anything that ‘slows’ down a team.  Once an impediment is fixed, we can expect an improvement in velocity (without any increased time or effort for the Team).

Impediments, though, are anything that is keeping the Team from being the best Team in the world.  Best in every way with the most business value, highest quality, most fun, highest productivity, etc, etc.

• Attack every day

Every day the SM should be getting someone to work on the top impediment.

• Incremental improvement every Sprint

Of course, we could have said ‘continuous improvement’ but we want to relate the concept to getting a small improvement in velocity (usually that is the metric) every sprint.  Now, this may not always happen (we are human, etc), and this may not always be possible.  But I strongly prefer to do things incrementally.

• SM plus the whole Team

The SM leads on this ‘getting better’.  The whole team must contribute.  For example, the Team must decide which is the biggest impediment (at some reasonable period), and the SM must get the Team to decide quickly.  And the Team’s motivation will change as they see their top impediment get fixed, over and over again.

I think dedicating about 1/7 of your Team’s time to getting better (especially when the payback of getting better is so great) is about right.  Ck Stephen Covey’s 7 Habits book, especially ‘sharpening the saw.’

• Get the Managers to help!!!

Of course the managers can and must help in removing the impediments.  And the Team must get the managers engaged.  I recommend making a business case (every other sprint?) to a manager, to get approval for $, for people, or for just approval to change things (often required).

It may take the Team some time to learn how to make these business cases (mostly benefits versus costs).  The Managers should take time to teach them how to do it better.

• It never ends

Be patient.  The path to becoming perfect never has an end point.  But it is also good to become better.

Never, never, never, never surrender to complacency.

Never surrender to the lie; ‘we can’t get any better’, or the more sophisticated lie that ‘the cost of any more improvements is greater than the benefit.’  The potential power of the Team is virtually immeasurable. Even the best Team has only tapped a small fraction of the potential of the Team.  Even champion sports teams are still far from ‘perfect’.  Records in every sport, expected to stand ‘forever’, are broken every day.

OK.  Once you gather the metrics and write the paper that shows how your Team became and is currently the best Team in Scrum ever, then you can take a day off from removing impediments.  Heck, take two days off. And then start getting better again.  As you know, once we get really good it is hard to stay at that level.  Very hard.

A few more concepts that I think are so obvious that I did not explain them today:

• A public impediment list will help. EX: It is hard for the SM to fix the impediments she does not know about.
• I recommend telling the truth to everyone.  Hence, a Public impediment list.  Yes, I know that’s ‘impossible’.  Mark Twain: “When in doubt tell the truth. It will confound your enemies and astound your friends.”
• Focus
• Work in priority order
• Plan a bit (adaptively)
• Use cost-benefit analysis
• KISS
• Single piece continuous flow (in this case: one impediment at a time)
• Aggressively attacking impediments is fundamental to Scrum, and key to its success
• Use metrics (with judgment)
• Culture is one of the key impediments; a ‘not good enough yet’ PO is a very common impediment; poor flow of business information (value and details) into the Team is a Universal impediment; better Continuous Integration and better automation of the testing is (are?) a near universal impediment(s)
• Yogi Berra: “Little things are big.”  If you improve 5% per Sprint, it will not take long to double your Team’s productivity.
• Of course, the world is so incredibly mucked up, that making huge improvements is easy. (I could cry or laugh, and I choose to laugh.)
• Convert normal human bitching to action.  Shakespeare: “Take arms against a sea of troubles, and by opposing end them.”
• Use the transparency that Scrum provides to help identify the top impediment to work on now. (Yes, the top one could change every hour.)

***

I hope these reminders helps a Team or two.

Feedback welcome!