Skip to content

Estimations: How I do it

Oct 16, 2014 - 4 minute read

Template Blog
Krzysztof Litwin
Previously I was a Software Developer, currently a Project Manager. Interested in agile project management, business development and startups. Big fan of common sense.
See all Krzysztof's posts

Finops Stickad Blog430x300


Throughout my career I have estimated work required for delivering a feature in various ways, such as man-days, man-hours or story points. I wasn’t always a project manager and, before now I used to be a decent developer. I am also quite experienced as a scrum master. This means that I’ve seen estimations from all sides of the table. Therefore, I believe that my understanding of the topic is quite good.


When I try explaining to someone what estimation is in an agile world, I find it really difficult to describe how and why, in my opinion, it should be done. It has taken me some time to get it right with this topic.

Imagine there is someone new in your agile project and you need to do some coaching. One of the elements that you would surely touch is estimation.

It differs depending if you have a new team member or a whole new team. Of course, in both cases there might be a different level of experience in the topic, but for me it doesn’t make a big difference as I start from the very beginning every time. I’ve seen so many approaches, so many might say it’s not the best technique that I assume it’s better to go through the topic from beginning to end. Of course the level of experience affects the overall time of discussions.

To begin with I explain that we estimate in story points, which are relative points, not time units, as we used to. I explain that we estimate total effort to complete a feature described in a user story and it is based on comparisons. There is a pack of relevant user stories which are well understood and already estimated or, in the future, a lot of stories done over time and possibly used as a reference for further estimations. To estimate we need to search through a pack of referenced user stories and find a similar story, with respect to complexity. This user story will tell us how many story points it has. Till now everything goes smoothly as it is the ‘easy’ theoretical part.

The real fun was always starting from this point. I would explain, in 20 ways, what complexity is, as it requires really good understanding and is not always so obvious. For me it was so hard to explain it fully without using references to time and it used to cause issues. Complexity explanation in short looked like this: how much time in total will you spend on this feature? On coding, testing, communicating with someone, investigating, releasing, and whatever else that might take your attention. Then pick from reference user stories similar one with respect to consumption of your time because complexity would surely be the same.

Then revelation came. Why am I talking about time if it is about relative points? Time shouldn’t be the issue here. Something is wrong, I thought. And it really was. I found that many people just count that this user story would probably take one person 5 days of work, so it is 8 story points. If this is the case, why use story points at all when we can use time to estimate instead?

Then I realised that it is very simple and confirmed the KISS rule - “keep it simple, stupid.” Just think of a user story that feels similarly big to you. Please don’t be surprised that it is about feel as all estimations also in time are about the same thing in the end anyway.. Just remember to adjust estimation accordingly, as each user story is different.

Usually when I say that it is better to use story points rather than time units, a fight starts.

People used to estimate in time units to such a high extent that a shift in thinking is not so easy. In my opinion people just need some time to give it a go and start feeling it, but it is also very easy to make mistakes when guiding your team mates in how to deal with estimations using story points. I can’t convince anyone with strong arguments that story points are better than time units apart from telling you that my experience says it all to me and only trying can prove it.

Some estimation schools teach that user stories should be estimated in story points, and tasks in hours. I was an advocate of this approach but now I believe that involving time here harms how people learn to use story points. It enhances the habit of involving time while estimating. The less add-ons you have, the more you can focus on things that really matter.

Be careful how you drive coaching process and, most of all, keep it simple stupid.

Finops Stickad Blog430x300
Krzysztof Litwin
Previously I was a Software Developer, currently a Project Manager. Interested in agile project management, business development and startups. Big fan of common sense.
See all Krzysztof's posts


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.