We estimate projects for two reasons:
1) To plan work
2) To monitor progress against that plan
On agile projects, estimation is usually done differently to traditional (waterfall) projects. But I am still seeing two distinct camps within the agile community
a) those who like to use story points to estimate the relative size and complexity of individual requirements and derive the expected duration from that, and
b) those who like to decompose those requirements into a task list and estimate the time taken to complete them.
I suspect that which option you prefer is a matter of your own personal thought patterns as much as anything else. Some people think top-down, others bottom-up. I know of a project manager who was a senior developer only a few years ago. His knowledge of the technical tasks required means that he is predisposed to the man-hours approach, whereas my development skills have been obsolete for quite some time, so I am predisposed to the story-points approach.
I personally have two problems with the man-hours approach (this post has a little theme of Two’s about it, doesn’t it?).
1) it is completely inaccurate. The aforementioned PM used to attend the daily ‘scrum of scrums’ and announce how many total man-hours of work his team had completed the previous day. The problem was it became clear very quickly that the team were nowhere near completing the tasks estimated. Now that, in itself, wasn’t a problem; it was just that they could never think of every single task required during a timebox so even if their individual task estimates were accurate, a lot of un-estimated tasks were being uncovered along the way. They were spending days doing task breakdowns and estimation. And features were not getting completed in time.
2) it measures effort to perform work, not time to complete valuable features. The expending of effort is, in itself, not particularly helpful. It is the delivery of completed stories and features that we are really interested in, so that is where our efforts should be concentrated.
So when it comes to measuring progress across the portfolio, I need to see a consistent measure. While it is pointless to compare man-hours or story points between project teams, I need to show that each team is doing all the following things:
– gathering requirements
– estimating the effort involved in delivering those requirements
– prioritising the requirements list
– deriving a delivery schedule
– monitoring progress against that schedule
– delivering features in priority order
It would not be difficult to set up a dashboard to show that all these things were being done, but I think that, to keep it simple, we need to use the same metric across all the project teams. My natural inclination is to opt for story points, but I have no intention of discouraging task breakdown and man-hours estimating. As long as they also estimate the story points.
I suspect that some teams will estimate in story points and call it a day, while others will break the stories down into tasks, estimate those and then derive story points from that. Does it matter? I don’t think so, as long as the team get better with their estimates over time. Those with experience of Lean development may say that too much time spent estimating is simply waste, and they’d be right. But that, too, is up to the teams to work out for themselves.
Your comments are most welcome.