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.
No comments:
Post a Comment