Saturday late evening, or maybe it’s already Sunday morning - you are drinking beer with friends in a bar. Some of you have normal beer mugs, some of you prefer those that looks like a big wine glasses. Pros use those big ones that spans from the table to their eyebrows. And it’s now your turn to pay for everyone. You take all those glasses from the table and you go the the bar. What will you ask the bartender, glasses of beer or liters?
You probably ask for glasses of beer. And with that you made a promise to the bartender to pay undefined amount of money for the beer. Price for the beer is per liter and you ask for filling different kinds of glasses. Doing this gives you better understanding of how much everyone wants to drink even if the final price for the beer is a bit unknown.
And those beers, if you haven’t figured that out yet, are the story points.
We could stop here if not for some details that require a bit more careful explanations.
Prepare a scale
Estimating in story points require preparing a scale, a list of our task examples for 1,2,3 etc. story points.
Skala story pointów.
How we should do this was described in details in my book Getting Things Programmed in the chapter titled„Szacowanie względne”(Relative estimating).
Let’s start from the fact that the scale is a must.
How many story points is it?
If there is no scale, when we try to estimate - by planning poker or not - everyone in the team ask themselves a question: How many story points it might be? Question in this form makes that every developer will ask about the tasks in the following way:
Universal estimating formula.
And I’m sorry but there is no way to escape this mental schema. Every time you ask“how much? - story points, man-days, cucumbers or chickens - a developer will use this magic formula.
Universal estimating formula.
Introducing the scale makes that we ask a different question To which of those tasks this new one is similar? This is a huge difference since we concentrate on comparison of tasks to each other - how they are different? how they are the same? – not on calculating this or that number of points.
Estimation with no precision
When team formulates, one of the first things is to include testes into the work structure such as refinement, estimation and planning. Sometimes a new person joins the team and doesn’t know all the complexity of software that’s being developed.
My observation is that, those testers are stressed when they are asked to give an estimate. It’s being solved with Planning Poker when we show our estimation on three.
Anyway, almost always there are discussion on things such as:
I don’t know the system - how I’m supposed to estimate?
maybe we should have developer’s story points and tester’s story points?
maybe everyone should have their own story points?
Using the scale and questions like To which task this new one is similar? eliminates those problems. We simply explain to the new team members in what sense those tasks are similar and in what sense they are different. New members has the opportunity to ask the killer-question that will shed new light on those tasks. There is no stupid competition“who gives the lowest estimate”.
Oh those story points…
Prepare a scale
How many story points is it?
Estimation with no precision
No, it doesn’t have to be Fibbonacci
OMG! They converted it to MD!