Tag Archives: estimation

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 »

Crisp for breakfast?

Posted on by

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 forecast delivery of software. A small revolution to how we do it today. If you are a program manager, manager, project manager or someone who needs to learn when I can get my things, this is the course to join.

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?

Establishing the first common product backlog

Posted on by

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.

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 »

We suck on estimating size

Posted on by

So, as a contracter:

  • Would you rather pick someone who promises they are right about the scope (.. lying..) and pay their risk premium
  • .. contract them, negotiate away the risk premium, only to see skilled resources shift to more profitable projects (once you are firmly in their grip)
  • .. contract them, and see them default
  • .. Or – pick someone who is honest about this fact, but promises to deliver runnable software monthly with what you require

As a contractee:

  • Would you sign up for a contract which you know is bad
  • Or pick a better client which you can have a thriving business relation with?

Just recently, I was approached by a startup company who needed a software built, and I was very honest about this fact. They went with another supplier. It stung a bit, but, just recently I heard that they have trouble with their funding. So in the end am glad I didn’t waste more time.

Sources and further readings:

  • Scott Ambler, Dr Dobbs Journal, "Is fixed-priced software unethical"
  • The Standish Group’s chaos report
  • "Stop estimating" – David Anderson
  • Software Cost Estimation with Cocomo II, Addison-Wesly 2000

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!