Triaging - Do you correctly triage additional item requests?

Last updated by Nick Curran [SSW] about 1 month ago.See history

"Triage" is a term originally used to describe the assessment of injured persons into a priority order based on the severity and urgency of their injuries. While developers don't often deal with real life and death situations, the ability to prioritise and action issues that arise can keep the heartbeat of a project steady and strong.

Managing additional work requests can reduce the adverse impact on estimates and deadlines. These work requests can include new feature requests, non-critical bug fixes, modifications and undiscovered work (i.e. work you didn't initially anticipate).

SuccessfulProjects Triage
Figure: Only if it's life and death does it get added "in this Sprint"

Prioritization

The first step is to prioritize the new work item.

  1. If it is a critical bug, call your Product Owner and add it to the current Sprint
  2. Otherwise, it should be added to the backlog:

    1. If the item is assessed as important, it should be placed immediately after the current Sprint items
    2. Otherwise, you should attempt to prioritize the item based on the existing items in the backlog

Note: On a fixed price contract, the rules change. Bugs should be fixed in the current Sprint if time allows, otherwise first thing in the next Sprint as they are stopping you from being paid.

Exception #1 - Critical Bugs go into the current Sprint

If you have a crash-to-code bug, most of the time it will go into the current Sprint. If it prevents one or more users accessing the system, it will also go into the current Sprint. High-priority bugs are fixed "in this Sprint".

Bugs are usually prioritised, so even non-critical bugs will likely end up in the next Sprint (via the Backlog).

Exception #2 - A client can override

A request for a new screen with a new look-up table that doesn't prevent users from operating the system, should be allocated to "a later Sprint". If the client really needs it done now, they must specify "must be in this Sprint". This will become an 'additional item' in the current Sprint.

If this request from the client will have a material impact on inflexible time and budget restraints, you need to speak and inform the client.

For example: "Hi Bill, this task you specified 'must be in this Sprint' will take an extra 4 days. Our critical deadline will be missed. Is that OK?"

Exception #3 - A Developer can override

A client may request a small feature (e.g. changing the sort order of a combo-box). This work can go in the current Sprint as long as the task is small (less than 1/2 hour) and the Sprint is not already slipping.

If the work is over budget, then you need to obtain approval for any 'additional item', from both the project manager and the client, before adding the request into the Sprint. See more about how to obtain approval for additional items that exceed estimates.

Figure: The above email sample from a customer will, by default, go into a future Sprint, not the current

We open source. Powered by GitHub