I was asked this a while ago and I’ve seen it mentioned a few times on blogs and forums and what not. I’ve answered it on a few occasions, so I thought I’d put it all into a coherent blog post.

Estimating a project before you start, with a brand new team is a tricky situation and one lots of people encounter.

There is a way you can work it out though, but your product manager should understand that it’s an **estimate** and** it will change**. If you need some backup, read this article on the ‘Cone of Uncertainty’ by Jeff Atwood and remember, you know the LEAST about a project right at the beginning!

## How can I estimate?

There’s two ways you can do this; based on points or based on hours. I’d suggest using the hours method as it will give you a range. You can get a range with points as well, but only when you’ve done a few sprints. Some people are against estimating in hours and, usually, I am too. But for this “beginning of a project with a new team” exercise, it’s invaluable. The below all assumes that you have a product backlog ordered by priority.

I’ll start with the points method (and, step 1!):

- Estimate, in story points, your entire backlog. This is easier than you think and is often called the white elephant method, we use it with great success.
- Draw up somewhere a grid with 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? as labels.
- Print out all your stories, or, if you’re already using index cards, just put them in a pile (but remember to put their priority order on them, so you don’t forget!) and put them in a stack somewhere.
- Now, each member of the team gets up, picks a story from the pile and sticks it to the board where they think it goes. If they have NO idea, then they put it in the ? box.
- Get everyone in the team to take turns in doing this. They must all do it in silence. Each turn they can pick up a story and place it on a board, they can also move a story that is already on the board, but they have to pick it up, face the team and say ‘I am moving this story because… ‘, then they can re-place it on the board.
- This goes on until all the stories are gone from the pile and no one is moving stories anymore.
- If you get two people moving a story back and forth because of a personal belief on it’s size, just have them put it in the larger number.

- Now, pick the story at the top of the backlog and say “Can we do this in two weeks?” If the team says yes, put it on the board, this board represents your sprint. Pick the next story and say “Can we also fit this story into two weeks?” if yes, put it on the board. Continue until your sprint is full.

Now, assuming you’ve story pointed all your backlog and the total is 260 points, you’ve worked out you can do 20 points per sprint, that means it’ll take you 13 sprints based on story points (so, 26 weeks). This will be quite wrong, but will give you a rough idea. If your product manager is bit simple, he might start telling everyone it’ll be done in 26 weeks. So, do the next step too:

- Ask each member of the team to estimate a max and min number of hours a day that they can work (taking into account meetings, phonecalls, emails etc etc that take time out of your productive, development hours); so Steve might say 4 – 5, Tina 5 – 6 and Hardeep 6 – 7. Work this out as hours per sprint. (So, Steve can do 40-60 hours per sprint in a two week sprint), with the above figures you’ll have a range of 150-180 hours a week;
- Remove all the cards from the board and put them back on the backlog;
- Pick the top story again, say “Can we fit this into a sprint?” If the team says yes, put it on the board again;
- Next, break this story down into tasks and estimate those tasks in hours;
- Do steps 3 and 4 until the team says they can’t fit anymore in the sprint based on the total number of hours (by adding up all the tasks) and their estimated man hours per sprint (ie: 150-180 hours per week as above), as a guideline, you should probably stop at around the 165 hour mark or, if the team cannot agree whether a story would fit or not, assume it won’t;
- Add up the number of hours they estimated, now you have how many hours they can fit into a sprint;
- Add up the story points for the sprint, this gives you your velocity.

So, you now do:

> total story points / velocity (from step1) = number of sprints based on velocity (don’t use this though, it’s a very rough guide)

> number of sprints based on velocity x (estimated hours for sprint (from step 2)) = total hours for project.

and then:

> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints

> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints

As an example:

> 400 / 20 = 20

> 20 x 165 = 3300

> 3300 / 150 = 22 sprints

> 3300/ 180 = 18 sprints

So, now you can say to your product manager, the project will take between 44 and 36 weeks (assuming two week sprints). Again, this is still only an estimate, but it gives you a better idea. Especially as you know the least right at the start. The best thing to do is provide continual updates to the PM. Once you’ve done a couple of sprints, you’ll have a better idea of your velocity and you should groom your backlog frequently (including re-estimating occasionally) to keep your estimated delivery fresh, based on the most up-to-date knowledge.

Another very useful article. Thanks for this.

I loved the Idea of how many hours everyone can work and they might say like “Steve might say 4 – 5, Tina 5 – 6 and Hardeep 6 – 7”.

What If I am lazy and say, 1-2 hours though?

Hi Pura, thanks for the comment!

You could say 1-2 hours, but then I’d have to ask: ‘WTF dude?’ as, either a) you’re telling me lies and you need your knuckles rapped, or b) there is actually a problem and you can only do 1-2 hours. If that’s the case, I’d add you as 1-2 hours so we can get on with the planning and look at the cause of why you can only commit such a small amount of time to the sprint. There’s clearly something impeding you that I, as a ScrumMaster, need to sort out! One we’ve worked out what that is (might take a few days) then we can recalculate based on your new estimate.

what a good Answer Mike.1-2 Hours is F** lazy.

Should this not be

> (total hours for project) / (lower weekly hours estimate) = maximum number of sprints

> (total hours for project) / (upper weekly hours estimate) = minimum number or sprints

Instead of

> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints

> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints

Hi Tarandeep,

The calculations here are:

> (Total Hours for project) / (your worst possible sprint) = longest possible project (This will always be greater than your best sprint).

> (Total Hours for project) / (your best sprint) = shortest possible project.

Thanks,

Mike

thanks Mike, i just got confused when i saw in original post above

> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints

> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints

Now, I understand, you are on the same page and original post had typo error.

thanks for replying, it was indeed a good post

Hi Mike,

I like your approach to come to a planning (do you know about Mike Cohn’s approach? Check on his website mountaingoatsoftware), but I got confused by the calc… Your example starts with a 2 week estimate, but you continue using single weeks as the base for estimates. Shouldn’t the calculation therefore be: 26 (weeks = 260/(20/2)) * 165 = 4290, resulting in max # (of 1 week) sprints = 29 (28,6) and min = 24 (23,8)?

Sincerely,

Erik