Introduction
When managing software projects, there are two main activities:
| Release Management | Project Management |
|---|---|
An activity which relates to the specifications of a product.
But you are not interested in tasks such as |
an activity which oversees the sequencing and execution of the tasks to complete a release
|
Although both activities are very related to each other, they are also very distinct.
iDalko created a concept of "Separation of Specifications and Tasks"(r), and implemented this concept on top of JIRA.
Problem Statement
Many organizations are using a single dimension approach for managing issues and the tasks necessary to resolve these. This translates into a JIRA setup with one project per product, where bugs are mixed with implementation tasks.
Issues with 'single dimension issue tracking': a simple workflow never remains simple
Typically every workflow starts very simple
In status 'Analyze' the engineer is asked to analyze the problem. The issue will be fixed only if it has been properly planned.
Reality strikes, some issues can be addressed immediately, so the next step is to adapt the workflow so that a developer can start right away:
Reality strikes again, the developer should be able to indicate that an issue needs more analysis. So a new transition is added. The workflow is being adapted to the actual way of working. You might imagine you end up with a very complex workflow to manage.
Single dimension issue tracking in a large team
Another example where the single dimension approach is getting into trouble if for instance an issue needs to be handled by multiple teams: in that case a typical approach is to duplicate issues, so that each team can process it separately. This has a significant negative impact as it skews the statistics (number of outstanding issues) and makes the integration of the deliverables of the various teams less transparent.
There is clearly a need for an alternative model where issues and the tasks to resolve them are tracked differently:
Multiple Dimension tracking
The tracking activity is simplified considerably by separating out the specifications from the tasks.
In this model there are 2 categories of issue types:
- Issues (bugs, improvements, new feature requests, test cases…) are used to track specifications descriptions how the product should (or should not) behave.
- Tasks (work packages, stories, code reviews…) are used to track work to do.
By separating these two categories, it is possible to create two dimensions one along the release management dimension and a second along the project management dimension. Some use cases
| Use Case 1: 1 issue, multiple tasks in a single team. |
Use Case 2: 1 issue, multiple tasks in multiple teams. |
Use Case 3: Multiple issues, single task |
|---|---|---|
A first example of separating out issues from tasks where multiple tasks are linked to one issue, is depicted in following figure. An issue is only solved, if and only if all related tasks have been solved. |
Another example is when a single issue needs to be handled by multiple teams. Each team can manage its own schedule, without the need to duplicate the issue. |
A third example where the "separation of specifications from tasks" makes sense is when multiple bugs related to the same root cause. Solving the root cause, will address all of the related issues. |
Solution applied
Types of projects
To implement this model on JIRA, we define 2 types of projects: Release projects and Team projects.
- A release project is used to track specifications (such as bugs, improvements and so on). The fix version in a release project denotes a release number (such 2.0, 2.3-patch2) Listing all issues solved in a release will be very simple..
- A team project is used to track work to do in the form of tasks, work packages, stories, and so on.
The fix version in a team project denotes a period (such as sprint 10, beta period,...) and is used to group all tasks that needs to be completed in such a period.
Linking issues to tasks
Using the link feature of JIRA, release issues will be linked to tasks to be executed. An issue is considered to be 'in progress' once that work on one of the tasks linked to that issue has been started. An issue is considered to be resolved, once that all the tasks linked to that issue have been finalized.
The relationship between issues and tasks is automated as part of the solution applied by iDalko. This automation supports following functions
- Auto transition a release issue to 'In progress' once that work on a related task has started.
- Auto transition a release issue to 'Resolved' once that all work on all related tasks have been completed.
- Auto transition a release issue back into 'in progress' if additional, unresolved tasks are linked to the release issue.
Benefits
The benefits of separating specifications from tasks should be clear. By managing both issue categories in a separate way, it is possible to improve overall software development activities, including release management and project management.
The use of JIRA in combination with the applied automation, provides a cost effective environment to realize a 'multi dimensional issue tracking' tool.
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.
