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

What’s this? An alien invasion? A publicity stunt? A way of sneaking Crisp into your cereals? You make the call. We Go Lean at breakfast, lunch and dinner! 🙂 This picture was forwarded by Troy Magennis, a Monte Carlo pioneer. PS: Troy is coming to Stockholm to show us how to use Monte Carlo to

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?

The past few days at my current coaching assignment have been great. We created a new backlog for all work they need to accomplish in the months ahead. The meetings where we laid the foundation for the future were marked by a high degree of collaboration between the participants and energy. It has been really fun to work with them so far.

Continue reading

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.

Continue reading

Before we consider agile contracting, or projects in general – there is one thing we must start to be honest about.

We cannot estimate a software problem accurately. In fact, our best estimate will most likely have a variance of at least 100 percent.  There is a reason why people like Alistair Cockburn calls this "the unsolved problem in software development.

• An upfront estimate replacing a 15 year old system I did with a team turned out to have a scope difference of over 100% in the end. To our help we had really skilled Business people with us all the way. (..we met the deadline and customer was excited but that’s an Agile story).
• Typically the scope ends at 189% of original estimate. (The Standish Group’s chaos report).
• Big upfront design results in over 45% of functionality never used (Scott Ambler , Dr Dobbs journal)
• There is a 10 to 1 productivity ratio between developers. So who does the job has a profound inpact (Software Cost Estimation with Cocomo II)

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 …