Project Setup : Release planning

Initial estimates of the software engineering time required for the development of a project are driven from the high-level product backlog and the “definition of done”. 

Backlog items should be given a priority between 1 and 4, with 1 being the highest priority.

The granularity of the estimates given is driven by the amount of detail provided in the product backlog.  At this point it is likely that the estimates will be ranges of effort reflecting the uncertainty of giving high level estimates.

Estimates are gathered by the team in backlog refinement sessions and are arrived at by playing planning poker.

Once the entire backlog is estimated, the software engineering effort required to deliver the described features has been established.

We are going to assume that software engineering is the constrained resource, and we will use the software engineering estimates to establish the number of sprints required to deliver the features.

Taking a two-week iteration, we will assume that each developer assigned to the project can work for between seven to eight days on features.  This leaves two to three days to fix bugs and resolve issues to create a potentially shippable product increment at the end of the sprint in time for the sprint review.

By resourcing the project with software engineers a projected sprint velocity can be established, and based on this projected velocity the number of sprints required to deliver the features can be established.

The required number of sprints can then be mapped onto a calendar to establish the elapsed time required for the development of the product backlog.

Product owner resource requirements can then be established considering the run up time required to prepare enough product backlog items for the first two sprints, and the ongoing product backlog refinement for the remainder of the development project.

Testing resource requirements can then be established considering the run up time required to prepare test cases for the first two sprints and the continuous testing required in each sprint to ensure a potentially shippable product increment at the end of each sprint.

Other resource requirements, such as user interface design, also need to be considered.

At the end of the development sprints it is unlikely, despite our best attempts, that the software will be fully ready for release, so stabilisation sprints may be required to resolve any outstanding bugs that would prevent the releases of the software to end users.

At this point the resource profile required for the development part of the project should be clear.