Your Zeroth Best Bet: Wait to Estimate Until You Know How the Team Works
If you have not worked on a project like this with this team, you have other problems. It’s not worth estimating the entire backlog at the beginning of the project, because the team members have no idea what relative estimation means to anyone else on the team. The team needs to work together. So, ask them to start together as quickly as possible. Yes, even before they estimate anything. They can work on anything—fixing defects, developing the stories for this product, anything at all. You all need data.
Since you have a ranked backlog, the easiest approach might be to start with a kanban board so you can visualize any bottlenecks. If necessary, use kanban inside an iteration, so you have the rhythm of the iteration surrounding the visualization of the kanban.
If you keep the iteration to one or two weeks, you will see if you have any bottlenecks. The shorter the iteration, the more often you will get feedback, the more valuable your data.
Once the team has successfully integrated several features, now, you can start estimating together and your estimates will mean something. Use the confidence level and re-estimate until the team’s confidence reaches 90%. How long will that take? I don’t know. That’s why you have a kanban board and you’re using iterations. I have seen new-to-agile teams take 6-7 iterations before they have a velocity they can rely on at all.
Your First Best Bet: Make Your Stories and Chunks Small
If you cannot wait to estimate, because someone is breathing down your neck, demanding an estimate, look at your backlog. How small are the stories? Here’s my rule of thumb: If you eyeball the story and say, “Hmm, if we put everyone on the team on this story, and we think we can attack this story together and get it done in a day,” then the story is the right size.
Now, you can add up those stories, which are about one team-day in size, give yourself a 50% confidence level, because you don’t really know, and proceed with “Use Timeboxes, Better Your Estimate as You Proceed” in Part 3.
Now, if someone is breathing fire down your neck, chances are good that no one has taken the time to create a backlog of right-size stories. But, maybe you got lucky. Maybe you have a product owner who’s been waiting for you, as a team, to be available to work on this project for the last six months, and has been lovingly hand-crafting those stories. And, maybe I won the lottery.
Your Second Best Bet: SWAG and Refine
Assume your manager has asked you for a date and you did not get empirical data from the team, but instead you decide to develop a SWAG, a Scientific, Wild Tush Guess.
SWAG Suggestions:
- If you must develop a SWAG, develop it with the team. Remember, a SWAG is a guess. It’s an educated guess, but it is a guess. You want to develop a SWAG the same way you estimate the stories, as a team.
- Develop a 3-point estimate: optimistic, likely, and pessimistic. Alternatively, develop a confidence level in the estimate.
- When you start with a SWAG, also start collecting data on the team’s performance that the team—and only the team—can use for the team to use to better their estimation.
- Refine the SWAG: Explain to your management that your original date was a SWAG, and that you need to refine the date. I like the word “refine,” as opposed to “update.” Refine sounds like you are going to give them a better date as in sooner. You may not, but you will give them a better date as in a more accurate date.
SWAG No-No’s
- Do NOT SWAG alone. The team gets to SWAG. It’s their estimate, not yours, as a project manager.
- Do NOT let your manager SWAG for you. Unless the manager is going to do all the work, the manager gets no say. Oh, the manager can decree a date, but then you go back to Part 3 and manage the project and re-estimate reasonably.
- Do NOT report a SWAG without a confidence percentage or a range attached.
So where does all of this get us with budgets and dates?
In many ways, estimating project budgets or dates for agile projects turns out to be irrelevant. If you have a ranked backlog, and you finish features, you can always stop the project if you hit a particular date or cost. It does matter if you have a ranked backlog, if you use an agile approach, or if you work in flow (kanban), or if you use a lifecycle that allows you to finish features (an incremental lifecycle where you integrate as you proceed).
That’s why I don’t get too perturbed when my managers try to fix the schedule and the feature set, and they rank the backlog. They can make the decision to stop the project if we run out of time or money. No problem. We are doing the best job we know how. I don’t have to sweat it. Because what matters is the ranked backlog.
To those of you who have programs, which have large budgets: yes, you do not want to burn through large sums of money without getting value in return. I agree. However, sometimes you don’t know if you’re getting any value unless you start something and have a chance to evaluate it via a demo to know if you’re getting any value. Your mileage may vary.
1. Remember, the project is a system.
We discussed this in Part 1. You have more degrees of freedom than just the feature set or the release date or the cost. You have the people on the project, the work environment, and the level of defects. If you are working on an agile project, expect to iterate on the end date or the budget. You can use rolling wave for agile projects or non-agile projects. Expect to iterate.
Because the project is a system and you will iterate, remember to estimate with confidence levels, both on dates and budgets.
2. Determine your preconditions for estimation
With a ranked backlog and knowing how to rank the vectors of your project pyramid, you can take a shot at a first cut at a date or a budget.
Never assume you know what is #1 for your project, #2 and so on. Ask. Sometimes, release date is #1, sometimes it’s not. Sometimes cost is #1, sometimes it’s not. Just because your manager asks for a release date does not mean that is the top priority. Ask.
If you are agile/lean and you do not have a ranked backlog, you are up the proverbial creek. Do not pitch a fit, but you cannot estimate. Explain that calmly and firmly. To everyone. Sure, you can start the project, assuming you have enough ranked stories for one iteration, or enough of a ranked backlog to start a kanban board. You don’t even have to estimate the project.
Why? Because the order matters. You can use dinner as an example. If you eat dessert before dinner, you might not want dinner. Why bother estimating how long it will take to make dinner if you’re not going to eat it?
In part 3, I suggested these options for when you had some idea of what was going on:
3. Use Timeboxes, Better Your Estimate as You Proceed
If you are using timeboxes, track your velocity and as you gain more confidence in your estimate, re-estimate the backlog and report it as you gain more confidence in your estimate. Go re-read part 3 for the details.
4. Obtain Data First, Then Argue
When you have a decreed end date and a decreed backlog, do not argue first.Do not bang your head against the wall. It hurts your head and does not change the situation.
I love it when the people who are not working directly on the project think they know more than you do. This is why I’m teaching influence workshops this year, in preparation for my program management book :-) This kind of thing happens all the time in program management.
Go re-read part 3 for the details.
Part 4 was all about how to estimate when everything was new:
5. Your Zeroth Best Bet: Wait to Estimate Until You Know How the Team Works
Can you estimate anything without knowing how this team will work on this project? I don’t think so. And, you should hedge your bet by keeping your iterations short.
6. Your First Best Bet: Make Your Stories and Chunks Small
Make the stories small so they are easier to estimate. Make any tasks small so you can estimate them Make the iterations small so you get feedback faster. Small is beautiful, baby. If you have anything larger than team-day task, you are in Trouble.
7. Your Second Best Bet: SWAG and Refine
Ok, you’ll fall for one of the oldest tricks in the book, but see if you can make it work. Estimate with the team, plan on refining the estimate. Please do not allow your estimate to be someone else’s commitment (an agile schedule game).
Don’t forget to read the SWAG No-No’s.
And those are my seven suggestions. Confidence percentages help a lot.
You can use these ideas for dates or budgets. Substitute “budget” or “cost” for “date” and you will see that the ideas fit.
I wish I could tell you there was a magic recipe or a crystal ball to tell you how to determine the unknown from no knowledge. There is not. You need data. But it doesn’t take long to get the data if you use an agile lifecycle. It takes a little longer with an incremental lifecycle. Yes, I will do a series on lifecycles soon.
If you found this series helpful, please let me know. It was a lot of work. If you would like even more about estimation, please see Manage It! Your Guide to Modern, Pragmatic Project Management at the Prags where you can see excerpts or at Amazon
where you can see more reviews. Yes, there is more about estimation. Astonishing, eh?
Reference: Estimating the Unknown: Dates or Budgets, Part 4, Estimating the Unknown: Dates or Budgets, Part 5 from our JCG partner Johanna Rothman at the Managing Product Development blog.
