SCRUM ESTIMATIONS DONE RIGHT

Many team members that I have worked with are confused about the use of the Story Points and are not even aware that the key concept behind it is the “Reference task”. I am going to clarify it with an analogy.

A NON-TECH ANALOGY FIRST

Let’s assume that you are a football (soccer) field maintenance manager that needs to plant new grass because the previous one is spoiled. You want to know the size of the field so that you can plan you grass purchase.

So, you ask two of your team members to measure its length. For the sake of the example, let’s assume for now that they do not have anything else to measure other than their footstep length. One of them is a tall guy, with a large step and the other one is not so tall, so, with a shorter step.

They start walking across the football field and when they reach the end, they provide their answer.

The tall guy reports that the football field is (let’s say) 100 steps in length. The shorter one reports that football field is 115 steps. Which of the two should you use to decide how much grass you have to buy? They are both right!

So, which is the right input to use in your materials calculations?

The answer is obvious -and that is the reason why I have started the article with this concocted situation- just agree on a unit and make your two “measurement guys” use it.

A standard unit of measurement is a quantifiable abstraction?that helps everyone understand the association of the object being measured with the outcome of the measure.

In the case of the football field, that unit would be the meter/metre (or feet, where that applies) and in the case of a SCRUM task estimation, that would be the “Reference task”.?

Let’s now move the example to our field (not soccer/football, but domain : ) )

THE REFERENCE TASK

Before providing the definition of the Reference task, note that the key value of a unit is that everyone agrees to use it. There is no real thing in nature as a “meter”. It is just an abstraction. (For those readers as freaky as me, here is the definition of a meter/metre).

The “Reference task” is also an abstraction that the SCRUM team agrees upon.

It typically works like this:

The team defines a task. Not too complex, not too easy. It can be anything that makes sense for that team: the development of a new API endpoint, a new ETL process, a new library or module. Whatever. It should have a scope that an average developer feels comfortable and familiar with.

Then -again- the team decides how many story points that Reference task corresponds. Let’s assume that they agree it will be 2 Story Points. Just because. Just like it was decided that the meter or the kilo are what they are.

The key point for the Reference task is that it is agreed (and understood) by the whole team.

NOW ESTIMATE LIKE THIS

Let’s say you have a new task to estimate. You already have a Reference task defined (2 Story Points assigned by the team), the whole team (junior and seniors) all understand it and have even implemented it.

(Hint: make the implementation of the Reference task one to do as part of the onboarding for any new team member)

Now you ask the team: ”What is your estimation for this new task?”

What you are really asking is:

“How many Reference task units is this new one?”

If a team member says: “it is 1 story point”, he is not saying “it would take me 1 day” to do it (Story Points DO NOT measure time) also not saying “it takes me 1 Story Point of effort” but he is really saying “this new ticket takes half the effort it requires the Reference task” (Remember, we agreed above that our Reference task was 2 Story Points)

Someone else might say that the new ticket is 2 Story Points. So, roughly the same effort as our agreed Reference task. (Then you would have to clarify it in the Refinement session. But that is another story).

So, the measurement unit abstracts the estimations from the particular situations of the team members. In the case of the football/soccer field the meter abstracted the length estimations from the footsteps and in the case of SCRUM, the Reference task abstracts the effort estimation from their seniority level.

THE REAL WORKD AGAIN: CAVEATS

Now the reality.

The above works beautifully when all of the other SCRUM premises are also met. Particularly a very important one: that the team is dedicated to software development.

The reality is that you oftentimes join a team where this is not exactly like that. Situations that I have faced:

• Some team members are software developers, some other deal with something else (i.e. technical support or DevOps)
• Team members are highly specialized: some only do API development; some others only do frontend development and the others do embedded coding
• Also, many times the types of tasks required are loosely related to development, like documenting or a spike

Many situations in the real world makes it not so easy to use the Reference task as an actual reference for the estimations.

There are some workarounds to minimize or, in some cases, overcome those situations. I have tried a few of them and if there is interest in the comments, I will write a follow up to this one with my experience on that topic.