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.
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