Tag Archives: estimating

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 »

Power Estimation

Posted on by

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?

What is the purpose of trying to improve estimates ?

Posted on by

I sometimes hear people talk about how to do better estimates. 
This often happens when the velocity for a team is going down and sometimes when it is going up too and when the estimated and actual velocity is much different.
Teams in these situations often seem to feel they have failed at estimating and thinks they should try to do a better job estimating.  
In my view this stems from a misunderstanding of the purpose of agile estimating.
I believe as many others, that estimates are always wrong, especially if you try to make them in actual time rather than relative size.
But even if you make them in relative size (story points) they are never anything more than guesses.
And with velocity tracking this is not a problem. There is really no big win in trying to "improve" your estimates.
The purpose of velocity tracking is to automatically correct the inherent error in estimates.
So let the automation built into the process work.

Suppose your team actually could get real accurate estimates.
Then your team would be able to pick the right amount of work for each sprint, and have a stable velocity.  

But then you can get this situation as easy with ordinary inaccurate estimates too, as long as the team makes about the same size of estimation error every time. 

Which they usually will given the same team members and a well-known problem domain.
So what should we do then when actual velocity starts to differ much from estimated velocity, is that not a sign of that the team is doing a worse estimation job? 
Not in my view.  Yes the estimates are apparently more inaccurate, but what is the reason for that ?
That is good information!   

The reason could be some of the following:

  • There is a new problem domain which the team is not used to
  • The team has got new members
  • The team has lost members
  • The team have moved or changed their physical environment
  • The team have started with some new practice
  • The team have stopped doing some practice
  • The team have got a new product owner
  • The team has grown tighter
  • The team has lost its energy
  • etc etc…

If you during a retrospective can try to find out why your estimated and actual velocity have started to differ you have good information to improve your effiency as a team and in the long run get more productive (not necessary higher velocity).

Just don’t try to estimate better.
And furthermore, don’t be *sorry* if your actual and estimated velocity differ!  It is natural that it happens, and will happen to most teams in a changing world.
I would be more worried if I were in a team with constantly stable velocity.
That would to me be a warning sign of stagnation.

And if you really want higher velocity, just start multiply your estimates with any high number.  In that way you can get as high velocity as you want.
Why you now would want that ?  🙂

Any good insight in this post I attribute to Mike Cohn.
He have taught me so much through his books "Agile Estimating and Planning" and "User Stories Applied" and his seminars. 
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com