Carsten Grønbjerg Lützen

Carsten Grønbjerg Lützen

Who am I?

I'm a SCRUM Master and Engineer at LEGO System A/S with an MSc in Computer Science and a soft spot for Software Engineering and methodologies. Hence here is my take on different agile and plan oriented methodologies and how we learn to use them effectively in our everyday life. Especially with an agile agenda.

Read more...


What I write about


Recent Posts

Story Points

What is story points? And can we even use them in complex IT projects?

How often do you hear the term "Story Point"? And how often do you get the feeling that your definition is not the same as theirs? I often find the definition vague and leaves a lot up to interpretation. Hence, this is my interpretation.

Relative Complexity or?

When you read a text book on Agile Methodologies you come across definitions of story points that goes something like this:

Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. [...] Agile FAQ

Story points are often modeled using Fibonacci Numbers: 1, 1, 2, 3, 5, 8, ... This is to minimise the risk of saying something is "twice" as complicated as something else.

But Do We Only Model Complexity?

Do we only model complexity in terms of how complicated a task seems to be?

I have met a lot of people that says Story Points models complexity and nothing else. But I do not agree with this.

Lets say we have a simple, yet repetitive task where we need to make the same configuration change on 10 servers. We know exactly what needs to be done, hence this should be a 1. We know exactly what needs to be done and could maybe even say how long time it would take.

But what value do we then get from the story points? It sparks discussions and aligment inside the team. But the Product Owner can't really use the story points for estimating when a story could be finished.

Of course, this is really valuable for the team but maybe not that useful for the Product Owner.

Can We Do Something Else?

We could of course just try to estimate in hours, but this have been shown again and again to be error prone.

I have previously worked with a two-dimensional estimation technique where one factor was technical debt the other was time. The technical debt accounted for missing documentation, missing tests, etc. And time had several intervals in the form of: 0-1 days of work, 2-3 days etc. These two numbers would then be inserted into a matrix to give you the story point. For that project it worked rather well, but could be a bit cumbersome.

Should We Try To Look at Effort Instead?

If we look at how much effort is required to implement a given story that would mean we would look at more factors than just complexity.

If we revisit the examlpe from before the story wouldn't get the lowest possible value but a value higher than that.

But why is that a good thing?

If we begin to look at effort as the thing we are using when we estimate that will capture a lot more information. For instance if we have a highly complex task we know that the effort required to implement such a feature will require a lot of effort. The same hold for uncertainty.

Hence, we should rather say: This story requires as much effort to implement as this other story, hence this story gets the same number of points.

But Why?

If we begin to estimate in relative effort, the Product Owner is much better equipped when he want to prioritize the backlog before the next sprint. In this way the Product Owner will, over time, get a feeling on how much effort the team can deliver in a sprint. This will of course vary from sprint to sprint, but it is likely to converge over time with small fluctuations.

And when it has converged it is a really valuable asset both for the team as a discussion starter, but also for the Product Owner, to guess on what can be achieved in a sprint.


Posted in Agile Methodologies on by

Share this post: