22

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

52

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.
  • 1
    Bounty!! Well said. – Mark C. Wallace Feb 7 at 14:12
  • 4
    From personal experience I've found the estimates provided by developers to be sound, if and only if you multiply against a magic number. I would recommend setting up a table of initial estimates vs actual time to delivery. As your sprints go on you'll be able to better estimate time. – Quaternion Feb 8 at 0:18
  • 5
    As a long-term developer who has worked with PMs for years, I suggest for a team of 4 developers or fewer you should multiply developer estimates by two for your magic number and you're likely to find your project estimates are reasonable. For each developer beyond 4 in a given team add 0.3 to 0.5 to that multiplier. I'm 100% serious as complexity increases as you assign personnel. – par Feb 8 at 7:52
  • 5
    After 25 years as a developer, looking retrospectively at estimates vs actuals - I find the "Magic Multiplier" is consistently 3. I work usually in teams of 2-6. – kpollock Feb 8 at 9:11
  • @kpollock yes that pattern that holds out on many projects, not just software: take your worst case estimate and multiply it by 3. Some developers learn to do that, some don't. I would recommend the article joelonsoftware.com/2007/10/26/evidence-based-scheduling – user1675016 Feb 8 at 16:30
11

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!

7

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.

3

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.

  • What do you do when you have low-risk, high-priority features and high-risk, low-priority features? How do you reconcile? – Sarov Feb 8 at 14:21
  • The prototyping stage is really for exploring high risk features. Features that are low risk will be similar to things done before so no need to prototype. The goal of the prototype stage is not to fully produce the feature, but to attempt it. Attempting to build a feature and discovering that it's much harder than first thought is an OK outcome at this stage. As per agile, each feature attempt is time boxed. Start with high risk/high priority and move to high risk/lower priority within a sprint. At sprint boundaries consider alternatives where a feature could not be built in time. – user85627 Feb 8 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.