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.

Continue reading

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.

Continue reading

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.

Continue reading

Why do you think projects always are late? That’s because they are designed to be late. But I’ll let you in on a secret: late projects are run by wimps. Unstoppable projects are run by masters. Welcome to the philosophy of power estimation.

You see, estimation isn’t about guessing how long a project will take, it is about getting power. More budget = more power. The best way to get more budget is to leverage the fear of failure by insisting on perfect estimation.

The beauty with estimation is the more people you ask, the bigger the estimation gets. So ask lots of people. Use historical data to cross reference how much off a project can get and grow your estimation by π. Feel the power now?

Teams often thinks they need to improve on estimating.
I think it is waste to try do that. 
But difference in actual and estimated velocity is good information, and nothing to be sorry about.
Mike Cohn have taught me this through his books "Agile Estimating and Planning" and "User Stories Applied". 
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com