Passing the baton workflow
To implement the ‘passing the baton’ approach, we adapted our workflow. Of course the approach is applicable to other workflows as well – our workflow has following steps.
- Open – whenever an issue is created
- Planned – the issue has been reviewed and we agreed who will tackle it by when
- In Progress – whenever someone is working on the issue
- On hold – whenever the issue is dependent on something else to happen
- Closed – Issue fully resolved.
We don’t have a ‘resolved’ status, because we found out that our customers will never confirm something is resolved. We therefore close an issue, and reopen it in case additional comments are coming in.
This workflow enforces that an issue has a due date set, and only the current user can assign an issue to him (or her) self. whenever the issue is in status ‘Planned’, ‘In Progress’ and ‘On hold’. You can use the ‘Fields Required’ validator of the JIRA Suite Utilities
Note – issues ‘On hold’ also require a due date as you want to be sure you followup also these little ones – else ‘on hold’ becomes a garbage bin.
How does it work
We review on a weekly bases the issues which entered the project (either through email, service desk, exalate or directly in the web interface). These are the issues in status ‘Open’ and unassigned. During the meeting we agree how should handle the problem and assign the issue.
The assignee then can decide to plan the issue, start working on it, or put it on hold. On either transition, a due date must be specified.
If the current assignee needs the issue to be handled by someone else, she (or he) mentions the person asking to take over the issue …
