Follow-up: A Way To Use Jira for Everything?

Today I continue yesterday’s discussion of ways to implement an RTM and my framework using Jira, except this time I want to talk about using Jira for every phase of an effort and not just for implementation and testing.

Given the figure below, which depicts my approach for reviewing the findings and outputs of each project phase with the customer before moving on, and also going back to previous phases to add concepts that might have been missed to support new items that were identified in the current phase, so complete two-way linking of all items is always maintained, I might ask why all items in every phase might not be handled in Jira as action items. There are a couple of possibilities.

Spawn New Issues from Post-Functions

An example of this was given in the course, where completed implementation items automatically spawned test items in a separate project. This is accomplished by specifying a post-function that creates a new issue during a transition of the existing issue, usually to a Done state, though it doesn’t have to be to a Done state. Indeed, it might be better to have it not be a transition to a done state. Instead, it might be a good idea to let the spawned issue or issues run to their own completion and then have them activate a transition to Done for the initial issue in some way.

One problem with this approach is that Jira doesn’t seem to include a create new issue post-function natively, although this capability appears to be available as an add-on from multiple vendors. An additional problem would be that there might be a problem with spawning multiple follow-on issues in the next phase from a single existing issue. A final problem is where to create the newly spawned issues. Do we put them in a new project? Do we create them in a separate swim lane? Do we create them in the same Jira project at the same level but with a different phase label?

Another approach is to add an ending transition for each item where it is sent to a specific team member (or subgroup) that is charged with creating the required follow-on issues manually. That requires a high degree of auditing by management personnel (ScrumMaster, Project Manager, or Transition Specialist).

It’s also possible to create sub-tasks, though I don’t think those flow across different phases very well.

Where Do We Put Newly Created Issues?

As asked above, where do we put issues from each phase of an effort? My framework defines seven possible phases, though that can be modified somewhat (for example, the Conceptual Model Phase could be split into a Discovery phase and a Data Collection Phase, while the Acceptance phase might be omitted).

If we put all of the items into a single project on a single board we’d have to identify items in each phase using some kind of label and then use a filter to view only the items we desire in each phase. This is a lot of work and does not provide much awareness across a whole project. That said, trying to show everything in a whole project might get pretty crazy.

In short, I think it’s probably simpler to manage items up through the design stage in separate-but-linked documents, with items possibly referenced in an overarching table of some kind, and handle the implementation and test operations as individual items within Jira workflows. This is how we operated on a large IV&V project I worked on for quite a while. The team managed an overarching document that included several intended use items while referring to separate documents for the requirements and conceptual model, along with a boatload of other materials. A separate development team tracked their own activities through implementation and test using one or more external work item management tools. Artifacts from those were referenced in the overarching tabular document.

When To Keep Things Simple

The foregoing discussion applies to efforts of a certain size and formality. Smaller efforts can be run on a more ad hoc basis using whatever techniques you’d like, including Scrum. In this case the discovery and conceptual phases can be folded into the requirements and implementation phases, and requirements and To Do items can be dumped right into Jira and processed from there. Managing a full RTM imposes a nontrivial cost, so you should be sure to incur that formal overhead only as it’s needed. It’s still a good idea to write out formal requirements, discoveries, and As-Is/To-Be diagrams and documents if possible.

This entry was posted in Management, Tools and methods and tagged , , , , . Bookmark the permalink.

Leave a Reply