Estimating

Estimating is a very important part of any project manager’s job. Wrong estimates lead to budget and schedule issues in your project. The best way to keep your schedule and budget under control is to be on top of your estimates, both before and during project execution. And you should be, as stakeholders and customers need to be able to rely on your estimates, for they have their own deadlines, targets, investment plans, marketing campaigns etc. that they need to plan as well. Delivering unreliable estimates and the corresponding unreliable schedules and budgets is simply unacceptable.

That being said, how do you come to reliable estimates for a project, if there is so much that is still unknown in the early phases, and so much to be learned and changed as the project is executed? When you start a project, make sure that there is a clear vision on what the project is supposed to deliver. This has to come from the product owner and project sponsor. Try to make sure that everybody involved in the project agrees on the vision; nothing can derail a project more than disagreement on this between senior stakeholders. Next, you’ll need an initial story map to start from. This has to come from the product owner. It should have all initial user stories and epics that would be necessary to implement the vision. The epics will be higher level and less precise, as the exact details will not yet be known. The most important user stories should be worked out pretty detailed, with acceptance criteria included enough to be able to start working on them in sprint 1. Other user stories will fall somewhere in between. Important is also that each user story and epic is as independent as possible from the other ones, i.e. it can stand on its own implementation and deployment wise, and it has business value independent of the rest. This is not always easy to achieve. Lastly, your story map must also includes enough nice to have’s. Since we consider scope our variable when we need to make decisions in order to keep the project on course, the story map, and later the backlog, must always contain some nice to have’s in case you need to drop something. If you don’t have these, you will be cornered immediately after a higher priority user story takes more budget and time than initially thought. And I think any project manager knows that this will happen.

Once you have this, you should think about which team would best be suited to implement this. In my experience, the best estimates come from teams that are also going to do the implementation. My experience with dedicated estimation groups who estimate a lot of projects that are then handed over to other project teams for execution is that they tend to miss a lot and produce unreliable estimates. But your experience may differ of course. I think it is a psychological issue; if you know you will be held accountable for the correctness of the estimate, and you also know you will have the power to take corrective action during the execution, you’re going to do a much more serious job. Another requirement for the team doing the estimation is that they have enough knowledge of the business domain and technology to come to sensible conclusions. That means you need at least a few experienced people on the team, who have done similar projects in the past.

So now you have a team and a story map. The next step is to schedule a few workshops with the team and the product owner to discuss the vision and the story map. This will lead to architectural and design discussions and decisions. It will also lead to changes to the story map, like new user stories, splitted user stories, rewritten user stories etc. Each time a user story is considered final, you can play planning poker to come to a story point estimate for it. Now of course you are not going to continue this until you have broken down all epics and user stories to 1 or 2 point stories. That’s just impossible. Usually 2 to 5 sessions spread over 1 or 2 weeks is enough the determine everything the product owner and the team know at this point in time, and the rest should become clear as the project moves along. So now you have a story map with some detailed user stories with small story point estimates, some less detailed user stories with larger story point estimates, and some epics with the largest story point estimates. All major architectural and design decisions should have been taken. The story map also contains some nice to have’s. The principal risks should also have been identified. At this point you have an estimate in story points for your entire project, which you can convert to a man day budget with 1 of the methods I described in my previous post. Or maybe you still have another method of doing that. Usually at this point I try to determine, together with the team, whether a risk premium is needed on top of the resulting man day estimate, and if yes, how high it should be.

When project execution starts, you will need to repeat this exercise regularly during backlog grooming meetings, so you can incorporate feedback and changes to the backlog. The backlog is of course a living entity, so some user stories will get dropped, new ones will appear, and other ones will need to be re-estimated based on what we learned. And of course it is vital that you keep track of any scope changes in your burn-up chart, so you can take immediate action when required.

OK, so you have your estimates, your budget and your schedule, and now your project sponsor or CFO says: That's too expensive to make a positive business case, make it cheaper. What to do? Well, asking your product owner which scope can be dropped, that's what you do. And again, make sure that not only the nice to haves are removed, because then you may run into trouble later in the project if one of your user stories comes in more expensive. If the project is like a pressure cooker, and the scope is what’s being cooked, then the bottom of your backlog is like its escape valve. If you don’t open it on time and let stuff out, the whole thing will blow up.

Another alternative that may be proposed is to look for cheaper resources. That’s fine, but I would at that point do the estimating exercise over again with the new team, because these cheaper resources may not have as much domain knowledge or experience, leading to higher man-day estimates. That would result in a different budget and schedule, than you would expect based on the daily rate alone.