Task estimation for PMs who are not developers

Question

While working Agile, how can a PM estimate a task when he/she is not a developer?

Answer 1

If at all possible, they don't.

They ask developers to estimate it.

Estimates should always be made by the people who will perform the work being estimated. If this is not done, then you run the following two risks:

1. The estimate is inaccurate, as the person who estimated it did not have the knowledge of what work needed to be done
2. The people who do the work do not have any buy-in for that estimate, and thus are less likely to have buy-in on any target or deadline for that same work, as well.

Answer 2

Have Task Performers Provide Estimates

In agile frameworks (and even in sensible non-agile frameworks), project managers should never estimate work items themselves. Instead, the people who will actually do the work ("task performers") do the estimation!

To get the most realistic estimates, have the task performers estimate the time and complexity of the work they will do. You want them to estimate based on their own skills, knowledge, and resources, because it doesn't really matter how long it would take for some other person to do the work. All that matters in a pragmatic sense is how long it will take the people assigned to the project to accomplish a task with the resources they have on hand.

If you must rely on third-party estimates for some reason (e.g. having a subject matter expert rather than the task performers provide a rough planning estimate), then you'll want to capture that person's assumptions, and then apply appropriate confidence intervals and fudge factors to the estimates they produce.

Express Estimates as a Range

The final product of any estimate should be a range, not a single value. Many practitioners target an 80% confidence interval, but bracket the target with pessimistic and optimistic targets as well. For example, you might use 60-95% as your initial spread, with an initial expectation of 80%. Just be sure you communicate effectively with stakeholders that any estimate is a forecast, and not an ironclad money-back guarantee!

Answer 3

It is very rare that this is possible. But it can happen, so let's look at it:

Any estimate is based off of statistical evidence from past experiences doing similar work. If the work we are doing is remarkably similar and we have a large set of data to work from, we can make estimates largely from categorizing the task. For example, I used to work in a data center and we built a lot of servers. From statistical data, anyone (including a PM) could tell you how long it was likely to take to provision a windows server on a particular piece of hardware. They could also look at the queue to see what the likely queue time for the work would be.

So, that's the kind of situation where it is possible. The reason that you got the other answers (which I completely agree with btw) about how you have to let the people doing the work estimate it, is because almost no knowledge work falls into this category - especially software development. Even if two features or applications look similar on the surface, they are usually very different behind the screen. So, from the PM's view, they will either find no similar tasks, not enough to make a prediction, or they likely do not have the depth of knowledge needed to really identify if a task is truly similar.

Here, we pass it off to the team. They also don't have similar tasks to compare it to, but they look much deeper into it until they get to similar tasks. For example, they have run queries against databases before. They've formatted data on the screen. They've handled input validation. Even still, it would probably be much more accurate to call these guesses than estimates, but they are at least educated guesses based on past experience.

Answer 4

As a former developer and agile pm, here's my 2p.

Some tasks are easy to estimate as they're a known quantity and have been done lots of times before. A sausage factory knows exactly how long it takes to make one more sausage.

Some tasks are impossible to estimate. A biotech company doesn't know if it will ever find a cure for disease x [insert some currently incurable disease here], it can only pursue promising avenues in an organised way.

Most development tasks fall somewhere between these two extremes, and a developer will usually have a good feel for where in this range any given task lies.

As a project manager, you can help this process by asking the developers to identify those tasks that are most risky/unknown, and separating these tasks into a separate stage where the output is a product prototype. The prototype will not have the engineering or robustness of the final product, but you will have put all the riskiest stuff at the front of the project when the least resource has been committed. If some feature turns out to be unfeasible, then you've found that out as early as possible and can alter course at minimum cost.

Once you have a working prototype, it's much easier for developers to plan and estimate the engineering required to turn the prototype into a deliverable project product.

One last thing, don't underestimate the difference between a prototype and a deliverable product. While it's more predictable, this difference will represent somewhere between 75% and 90% of the total project effort.