Tag Archives: story points

Bucket Estimation – How to estimate a really large backlog

Posted on by

So you have a LARGE backlog and you have decided that you need to estimate it.

Not on board? Still undecided? Go read my previous post on the tradeoffs between estimating and not estimating large backlogs.

Still reading? Ok, let’s get to it!

You can do larger scale estimation in MANY ways. What I will share with you here is just one way I have found to do it effectively, with enough accuracy at a reasonable cost. It requires some pre-conditions, such as having a team with an established way of working and some way of estimating on the team level, so it may not fit your situation. But if it does it is probably worth your time to check out.

read more »

Large Backlog – To estimate or not, that is the question!

Posted on by

Estimation seems to have gotten a bit of a bad reputation lately.

One misconception I sometimes see is that estimation beyond just a few weeks is “not agile”. Another trend is that some people advocate against doing estimation at all mostly because they view it as a beginner tool, so by not estimating we are no longer beginners.

To me doing estimation or not does not really say much about “how agile you are”. The way I look at it is that we should estimate when the reasons to do so outweigh the reasons not to do so. That simple.

In some scenarios this also includes doing estimation of large backlogs.

So in this article I want to share what I see as some of the reasons FOR and AGAINST doing estimation of a larger backlog. You can then decide for yourself if your situation justifies doing it or not.

read more »

Time vs Story Points Estimation

Posted on by and

One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.

Let us give you the travel metaphor to give you an idea about how we are thinking.

read more »

Steve Bockmans team estimation

Posted on by

Estimation of the effort to implement and deliver a set of functionality is an important but not always the most fun part of product development. Estimations are done at different detail levels during the project, for example the high level story estimation and the low level task estimation. It is a few years since I did task estimation; many times it is a waste of time doing low level estimations, so in the following text I will describe a technique that I like when estimating the user stories.

read more »

Three reasons why story points are better than ideal man days for estimations

Posted on by

I often hear from Scrum teams they don’t understand why estimating in story points are better than estimating in ideal man days. Here comes three reasons:

Reason 1. Estimation is a way of telling the size of a story, not how long it takes to implement it. If you give the size in a unit that sounds like a time people will likely mix things up. If you have persons in your organization who are control freaks it’s hard to explain why a story with size 5 ideal man days takes two weeks to develop. If one of the control freaks is your manager you will probably be asked to cut down on Scrum stuff like daily Scrum or retrospective or what ever you are doing the 50% of time you are not developing.

Reason 2. Scrum has a potential to make you four times more productive. Let’s say you are a development team of five people and have estimated a whole project in ideal man days and you start with a focus factor of 50%. That means you can include stories representing about 35 ideal man days in a three week sprint. Let’s say you actually become four times more productive which means you can handle stories with summarized size of 140 ideal man days in a timeframe of 5 persons * 14 days = 70 calendar man days which means you have a focus factor of 200%. Does that sound weird to anyone? Ideal man days is a size that varies over time depending on team performance. If you don’t understand the calculation the last paragraph might help you.

Reason 3. It’s proven that relative estimation is more correct than absolute and since ideal man days is a time measure it’s easy to make absolute estimations even though it could be used relatively as well. Story points has no meaning without something to relate to which means those estimates can only work for relative estimations.

My recommendation is to estimate in story points and use velocity to calculate the time just like you do for driving. The distance divided by your velocity gives the time it takes.

This is how you can get started. Take a well known task/story as your standardised benchmark. If this a rather small story, set it to two story points so you have room for smaller stories. Estimate the rest of the stories relative to this.

Before our first planning meeting we need to know our velocity so we know how much we can commit to. But we don’t have that since we don’t have a history.

To get an initial velocity for our first sprint, we estimate the selected standard story in ideal man days. Let’s say the story is 2 story points and 4 ideal man days, we then know the team can handle 1/2 story point per ideal man day. Use the focus factor to convert ideal man day to calendar days. The focus factor is typically between 50% and 70% depending on the amount of support and interruptions. If the focus factor is 50% we can handle 1/4 story point in a calendar day (1/2 * 50%). If the team consist of five people and the sprint is 14 days we have 70 calendar man days in the sprint. 70 * 1/4 gives that we should be able to bring 17 story points into the sprint. Finally we have our initial velocity.

Good luck!