Tłumaczenie wpisu “Ach te story pointy”.

# ​​Oh those story points…

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.
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:
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.
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”.

## ​​No, it doesn’t have to be Fibbonacci

nor powers of two. For more explanations see Getting Things Programmed.

## ​​OMG! They converted it to MD!

They teach us not to convert story points to man-days because… something terrible will happen.

It leads to funny situations. Below few quotes that I’ve encountered:

• now, since everything is in story points, we don’t know how much it will take teams to develop a feature
• we told the business it will take 200 SP but they seems to not understand it
• it’s not allowed to asked teams when they will finish the feature since story points is complexity and not time