Requirements Estimation

Rationale

At the start of every cycle the TSC presents a set of requirements that they wish to see in the next release.

These requirements are refined with the help of the tech leads to produce a set of Technical Requirements.

In order for this process to work well there needs to be a negotiation between the TSC and the techleads over the amount that can be done in one cycle.

For the TSC this is important because they want to ensure that they are getting the most value out of the engineering teams.

For the techleads it is important because they want to ensure that they only commit to work that they can achieve in a cycle.

The negotiation phase finishes with a set of TRs that must be completed within the cycle, those on which some progress should be made, and those which can fill in the gaps should other work finish ahead of schedule.

In order to do this well each task needs to be estimated. The techlead will do this to some extent, but may not record their estimate or share it with anyone.

Given the estimates for each TR it is possible to do some easy sums to work out how many of the TRs the team would complete (assuming that the estimates are accurate).

In order to reduce the error implicit in these calculations it is possible for the techlead to broadly assign tasks to engineers within the team, and then to repeat the calculations at the per-person level.

In fact it is then better to present the information in a graphical fashion, similar to the way Michael Hope has done previously, so that it is easy to see whether workload is balanced across the team.

Requirements

Essential:

  • Record an estimate per-TR.
  • Assign a TR to a person
  • Visualize the workload for each person

Nice to have:

Gantt Charts

Gantt Charts won't work very well for this for several reasons:

  1. They require specifying an ordering on tasks which we don't have at this time, and picking an arbitrary doesn't buy us anything
  2. They require picking start/end dates for the tasks, and again we don't have them, and they wouldn't buy us anything

They do however have some properties that we wouldn't have with such a system:

  1. We would assume that contention on people's time, tasks being blocked etc. are accounted for in the estimate, rather than being explicit so that they could be avoided

internal/archive/Platform/Infrastructure/Specs/RequirementsEstimation (last modified 2013-08-23 02:04:03)