Estimating Software Projects/Tasks
This article describes a process for estimating software projects/tasks by engineers on Product Teams. It’s being adopted to improve the visibility/timeliness of work on said projects/tasks. To that end, the engineers on each Product team shall be responsible for providing good-faith estimates -- before starting any development -- for every project/task assigned to them by their Tech/Product Leads. Relatedly, it shall be the responsibility of the Tech/Product Leads to provide detailed product descriptions/designs to their engineers -- as well as time to do research/work-breakdowns -- for every project/task that they assign to them. In doing so, it’s believed that projects/tasks will be more accurately estimated and delivered.
What’s an estimate?
An estimate, in the context of Agile software development, is an educated guess or prediction about how long a particular project/task will take to be completed. It is not a fact; meaning, an estimate can and should change once new information about the project/task becomes available and/or the resources working on it change.
Why do estimates?
Estimates are for planning purposes, specifically, to help the product/business stakeholders figure out when a project/task is likely to be completed. Estimates also help in terms of prioritizing, scoping, and figuring out costs for various projects/tasks.
Who's responsible for providing estimates?
The person(s) who’ll be working on the project/task; specifically, the engineer(s) to whom the project/task will be assigned! The following individuals should almost never (only in absentia) give an estimate for work to be done by an engineer: Product, Marketing, Sales, QA, CS, etc.
Which metric should be used for estimating?
Story Points, which are based on the Fibonacci sequence, i.e., 0, 1, 2, 3, 5. Note that Story Points are for measuring an engineer’s level of effort/complexity only. It does not take into account meetings, lunches, sick days, vacation days, work-from-home days, etc. Therefore, all Product/Tech Leads are highly encouraged to include additional time for such eventualities when calculating the delivery date for a particular project/task. Listed below is a mapping of story points to man-hours to aid in forecasting; it’s mainly for the benefit of product/business stakeholders. Engineers should never estimate in man-hours, only story points.
How likely is an estimate to be accurate?
The accuracy of an estimate depends on the person(s) doing the estimate and on the information available to the person(s) at the time. If either of the aforementioned changes, the originally given estimate should be updated. In general, an estimate tends to be less accurate for larger, less well-defined projects/tasks. This is illustrated by The Cone of Uncertainty below, which represents the error in estimates created by skilled estimators. It’s easily possible to do worse, but it isn’t possible to be more accurate; only luckier.
What’s necessary for an accurate estimate?
When to do estimates?
Estimates should ideally happen during Backlog Grooming meetings. A Product team’s Tech/Product Lead should send them a list of User Stories ahead of time and ask them to review the stories and come prepared with questions, tasks, initial estimates, etc. During the meeting, it’s vitally important that the Tech/Product Lead keeps in mind that any initial estimates are likely to change once more of the story’s details come to light, or even after development work begins.
How to do estimates?
Ideally, an engineer will use a reference story to help them estimate the relative size of a newer story. In so doing, the engineer must factor in things like the level of effort, amount of work, and complexity of the newer story relative to the reference story. The engineer is free to use any of the following methodologies (or an entirely different one) to do their estimates (see also WBS, Estimation and Scheduling by John Musser for more information). Note that the estimation process for a particular story shouldn’t take more than 30 minutes; if more time is needed, the engineer should speak with their Tech Lead before doing additional work.
What are some examples/scenarios?
What’s an estimate?
An estimate, in the context of Agile software development, is an educated guess or prediction about how long a particular project/task will take to be completed. It is not a fact; meaning, an estimate can and should change once new information about the project/task becomes available and/or the resources working on it change.
Why do estimates?
Estimates are for planning purposes, specifically, to help the product/business stakeholders figure out when a project/task is likely to be completed. Estimates also help in terms of prioritizing, scoping, and figuring out costs for various projects/tasks.
Who's responsible for providing estimates?
The person(s) who’ll be working on the project/task; specifically, the engineer(s) to whom the project/task will be assigned! The following individuals should almost never (only in absentia) give an estimate for work to be done by an engineer: Product, Marketing, Sales, QA, CS, etc.
Which metric should be used for estimating?
Story Points, which are based on the Fibonacci sequence, i.e., 0, 1, 2, 3, 5. Note that Story Points are for measuring an engineer’s level of effort/complexity only. It does not take into account meetings, lunches, sick days, vacation days, work-from-home days, etc. Therefore, all Product/Tech Leads are highly encouraged to include additional time for such eventualities when calculating the delivery date for a particular project/task. Listed below is a mapping of story points to man-hours to aid in forecasting; it’s mainly for the benefit of product/business stakeholders. Engineers should never estimate in man-hours, only story points.
How likely is an estimate to be accurate?
The accuracy of an estimate depends on the person(s) doing the estimate and on the information available to the person(s) at the time. If either of the aforementioned changes, the originally given estimate should be updated. In general, an estimate tends to be less accurate for larger, less well-defined projects/tasks. This is illustrated by The Cone of Uncertainty below, which represents the error in estimates created by skilled estimators. It’s easily possible to do worse, but it isn’t possible to be more accurate; only luckier.
What’s necessary for an accurate estimate?
- Detailed product descriptions
- Well-defined User Stories
- Finalized UI/UX designs
- Time for research/work breakdowns
When to do estimates?
Estimates should ideally happen during Backlog Grooming meetings. A Product team’s Tech/Product Lead should send them a list of User Stories ahead of time and ask them to review the stories and come prepared with questions, tasks, initial estimates, etc. During the meeting, it’s vitally important that the Tech/Product Lead keeps in mind that any initial estimates are likely to change once more of the story’s details come to light, or even after development work begins.
How to do estimates?
Ideally, an engineer will use a reference story to help them estimate the relative size of a newer story. In so doing, the engineer must factor in things like the level of effort, amount of work, and complexity of the newer story relative to the reference story. The engineer is free to use any of the following methodologies (or an entirely different one) to do their estimates (see also WBS, Estimation and Scheduling by John Musser for more information). Note that the estimation process for a particular story shouldn’t take more than 30 minutes; if more time is needed, the engineer should speak with their Tech Lead before doing additional work.
- Top-down
- Based on the overall characteristics of a project/task
- Advantages
- Easy to calculate
- Effective early on (like initial cost estimates)
- Disadvantages
- Some models are questionable or may not fit
- Less accurate because it doesn’t look at details
- Bottom-up
- Create Work Breakdown Structure
- Add from the bottom up
- Advantages
- Works well if activities are well understood
- Disadvantages
- Specific activities are not always known
- More time-consuming
- Analogy
- Use a past project
- Must be sufficiently similar (technology, type, organization)
- Find comparable attributes (ex, no. of inputs/outputs)
- Can create a function
- Advantages
- Based on actual historical data
- Disadvantages
- Difficulty ‘matching’ project types
- Prior data may have been incorrectly measured
- How to measure differences – no two are exactly the same
- Expert Judgment
- Use somebody who has recent experience on a similar project - not easy for software!
- You get a “guesstimate.”
- Accuracy depends on their ‘real’ expertise
- Comparable application(s) must be accurately chosen
- Systematic
- Can use a weighted average of opinions
- Priced to Win
- Just follow other estimates
- Save on doing a full estimate
- Needs information on other estimates (or prices)
- The purchaser must closely watch trade-offs
- Priced to lose?
- Parametric or Algorithmic Method
- Lines of Code (LOC)
- Function points
- Feature points or object points
- Other possible
- Number of bubbles on a DFD
- Number of ERD entities
- Number of processes on a structure chart
- LOC and function points are the most common
- (of the algorithmic approaches)
- The majority of projects use none of the above
- Wideband Delphi
- Group consensus approach
- Rand Corporation used a Delphi approach to predict future technologies
- Present experts with a problem and a response form
- Conduct group discussion, collect anonymous opinions, and then provide feedback
- Conduct another discussion and iterate until consensus
- Advantages
- Easy, inexpensive, and utilize the expertise of several people
- Does not require historical data
- Disadvantages
- Difficult to repeat
- May fail to reach consensus, reach the wrong one, or all may have
- same bias
What are some examples/scenarios?
- A developer walks onto an elevator… with their Product Lead behind them.
- Product:
- I’ve been meaning to talk to you about a new material that we want to launch in December. How long will that take to do?
- Engineer:
- Using the Analogy estimation methodology… If it’s like the other materials we’ve launched in the past, it shouldn’t take more than 2 Story Points.
- A Product/Tech Lead walks over to an engineer’s desk
- Product/Tech Lead:
- The Sales team has a vast sales opportunity with Heroforce to produce a set of dice for them. We’re trying to figure out a price quote for them and need you to estimate the level of effort/complexity.
- Engineer:
- Using the Expert Judgment estimation methodology… You should probably talk to the Members Only team about that since they’ve done a lot of work for Heroforge in the past.
- Members Only team:
- Using the Top-down estimation methodology… Based on the details you’ve shared, it’ll take about 5 Story Points.
Comments
Post a Comment