How to define Columns and Status in JIRA to make sense for all issue types (Tasks, Epics, etc.)

Question

Background: JIRA offers a single set of statuses for all types of issues in a project.

Problem: The problem is that the status set for a task is ToDo, InProgress, and Done. While for a UserStory in the same project it might be Designing, Developping, Testing, Releasing, and Done. It can even be different for a bug or an Epic.

Question: How do you keep track of the workflow of your product and at the same time manage the status of your tasks using the single set of JIRA status.

PS: I know they can be customized for each project, but it doesn't help because you can't customize them for each issue type separately.

Answer 1

The statuses that are available to each project is determined by the Workflow to which it is assigned. Not only does a workflow define the statuses, but it also defines what statuses you can progress to from a particular status. You can either create your own Workflows or you can download predefined workflows that suite your need. In order to have separate workflows for different issue types, we need to define a Workflow Scheme:

1- Go to Jira Administration -> Workflow Schemes

2- Edit the Wokflow Scheme that is assigned to your project

3- Click the "Add Workflow" to add a new workflow for the issue types for which you need a different workflow and assign those issue types.

Answer 2

I think one of the reasons that JIRA offers the To Do, In Progress, and Done is that these can apply to anything. You either haven't done it, you're doing something, or you finished. That set can apply to any type of item.

That being said, I feel your pain in wanting to have a better view into the true state of an issue. What we have found we use for our OnDemand agile boards is to set up something like the following:

1. To Do
2. In Progress
3. Ready for Review
4. In Review
5. Done

For most types of issues, this can work. It adds that bit of extra layer to be able to identify what is ready for testing.

One of the things that is tricky is dependent tasks. For example, I noticed you mentioned "Designing" as a stage, and I'm not sure this makes sense in an agile sense. If the design is emerging from the development, it may be better to allow the design/development to flow within the development team. However, we all know that sometimes you need to get some details ironed out before you can proceed, or there may be some people that need to become involved before a dev can proceed. We made the mistake of trying to turn this into a stage, but what we found was that this was really either a sub-task for part of the team, or an impediment (blocker). By flagging stories, you can identify that a story requires something to be done before the development team can proceed.

If you are using Kanban, and not a Scrum board, the sub-task approach will not be for you. In those cases, you'll just need to make sure you have stages that make sense for all the issues you create. Stages will have to be fairly 'generic'. This sounds bad.

But it is not!

I believe teams generally use the stages for a few reasons:

1. Checking on status of an iteration
2. Inform other team members that they can pick up an item
3. Try to get a visual estimate on how close to Done an issue is.

More stages doesn't necessarily give a better status on an iteration as you really just need to see how many points you've closed and how many are in progress. So, at least for that goal, a more generic set of stages should work.

As for informing team members, too often I've seen teams retreat to the digital board to replace communication with each other. The fewer stages you have, the more you can force your team to talk to each other and work together to get a story to done. Things will work better this way, I guarantee it! Having a bit of a break-down helps, especially if you are working on a lot of items at once or have distributed teams working in different time zones, but keeping it simple is usually better.

Tracking the "how close to Done" is the hardest to do with generic stages. However, the multiple stages can be misleading. An item that is almost all the way across might have a severe bug in it that hasn't been found yet, so no matter how many stages you have your view on this item isn't any more accurate than a single "In Progress" stage. It isn't Done until it's Done :)

This was a long way for me to recommend keeping your workflow simple and letting your team use communication to keep on top of things. Maybe I should have just started with that!