Who this guide is for

This post is for people who are new to estimating software development tasks or want to take a more structured approach to it. It isn't meant for scrum masters, seasoned project managers, or JIRA ninjas. It's meant to get you thinking about the problem yourself rather than be a dogmatic methodology.

The problem

Odds are your existing estimation process looks like this: a stakeholder asks a developer when something will be done, writes that down, then informs other stakeholders. End of conversation. You probably haven't even agreed on a definition of "done", let alone carefully considered all of the known and unknown factors involved in that estimate.

Some teams are more collaborative, using methods like planning poker to form estimates. This is great, and if it's working for your team then you should continue to use it. However, if your team is small or inexperienced you'll likely find yourself in need of some additional structure.

The factors

Using an agreed-upon set of factors is a great way to objectively come up with a time estimate. This forces everyone to recognize risks and unknowns ahead of time and adjust for them so everyone can manage expectations. Here are the factors I like to use:

1. Developer experience level
2. Requirements definition
3. Frontend difficulty
4. Backend difficulty
5. Testing plan maturity & difficulty
6. External dependencies
7. Deployment difficulty

The guide

There are two parts to this guide: individual task estimation and aggregate task planning. This spreadsheet will help illustrate the concepts; please feel free to make a copy of it for your own use.

Individual task estimation

Starting with a gut-feeling base estimate, we can use the above factors to estimate any given task. Most developers have a reasonably good feeling for how difficult a given task is, so that's a great place to start. Proceed to rate each factor on a scale of 1 to 5, with 5 being the best. For example, if there is no frontend work for a given task then rate it a "5". If the requirements are poorly defined, give that a "1".

The other factor here is how confident you are in these ratings. This is on a percentage scale and serves to quantify the unknown factors inherent in all software projects. Confidence level impacts the overall estimate in a huge way, and this is on purpose: if the estimate is too large as a result of it then the team needs to gain confidence by doing research, testing out theories, etc.

Aggregate task planning

As you estimate individual tasks you can then begin ranking them by priority and effort. Simply rank priority as you did the factors, on a scale from 1 to 5 with 5 being the most important. Be sure to evenly distribute your priority rankings! You should end up with 20% being 1, 20% being 5, etc. Remember: if everything is high priority then nothing is.

For the effort column, you can simply enter the estimates you generated from the individual task estimator. Alternatively, you can simply estimate effort on the scale of your choosing. From there it's a short trip to estimate completion dates for each task. Avoid creating estimates by assuming 8 hours of effort per day! You have to include developer time spent on other stuff (meetings, documentation, etc.) or your estimates will be way off.

Build to suit

As I mentioned, this is spreadsheet is meant to get you started and may have some flaws. Before putting it in to practice, be sure to evaluate how the formulas work! You should modify the factors and formulas to fit your organization.