Problem statement

Every software development organisation needs to decide what the content of the next release will be.
This ‘release content decision process’ is always an iterative approach where priorities depend on the cost of developping such a feature.

At each cycle more detail will lead to better estimates and a more accurate ROI projection, and thus increase the efficiency of the choices.

Email and face to face meetings doesn't scale well, especially when a large number of geographically dispersed teams need to participate in this process.

The objective of the collaborative story estimation project is to deliver an environment where the estimation of the Project Requests can be coordinated and improved.

Solution applied

Project Setup

An estimate tracking tool has been implemented on top of JIRA by defining 2 issue types:

• Project Requests
• Deliverables

Basic estimation cycle

Project requests are typically change requests, feature enhancements at a business specification level.
These come in the form of a couple of slides, ideas jotted down on an email, or discussed during a meeting.
Given that we want to track this idea and know what it would cost to implement, we follow following scenario

1. We create a new project request and start a transition 'Add deliverables'
2. Based on the type of request, a list of subtasks (of type Deliveable) is automatically created. Typically tasks such as 'develop feature', 'validate', 'Integrate' ... and assigned to the respective appropriate person .
3. Each of the leads is going to discuss with the team the deliverable and what it would take to deliver it.
4. When an estimate is available it is entered in the deliverable (using the JIRA timetracking features), and the deliverable is reassigned to the request owner.
5. Once that all the estimates have been provided, the project request is automatically progressed from status 'in estimation' to 'estimated'.

The prioritisation of the project requests is managed using the agile plugin.

Blocking estimates

Typically an estimate cannot be completed if some information is lacking. A deliverable will be progressed to status 'blocked' signaling to the project requests that the estimation process is interrupted. Automation scripts will ensure that the project requests will be flagged as blocked and proper notifications are sent out.

Reestimating a project request

As details about the new request become available (trough discussions on confluence or by analysis work), it is possible to run a new estimation cycle, where all deliverables which have been estimated are reset. Users will be notified of pending estimation work, and the cycle is restarted.

Calculating a contingency buffer using the 50/90 Technique

The project request contingency buffer is automatically calculated using a proposition as described in Chapter 17 of Mike Cohn’s book Agile Estimating and Planning. For each deliverable we provide two figures, a realistic estimate and a worst case estimate
In this approach, our “realistic” estimate is the value at which we have a 50% chance of the task taking longer than the estimate, and a 50% chance of the task taking less than the estimate. If the distribution were symmetrical (unfortunately, it’s not), this would be the midpoint. A useful, but slightly inaccurate way of thinking of this is as the “most likely” case estimate. The “high” estimate is the value at which we have a 90% chance of completing the work in less time. Making the 90% estimate requires either a lot of confidence and knowledge, or a really high estimate. On a task of high variability or unknown elements, the spread between “realistic” (50%) and “worst case” (90%) can be quite large.
From this figure we will calculate a contingency buffer where the buffer is calculated as

More information

Please contact us for more information how this model can be applied for your software development, or for a demonstration of the setup.