2009-03-23

Done with Jira

Great--now the team has a rough agreement on what Done means.

Not great--Jira disagrees with us.

Here's the problem. Semantically, we divide our work tasks into two categories: Not Done and Done. Jira semantically divides issues into statuses "open" and "resolved"; syntactically, Jira groups issues with statuses {Open, In Progress, Reopened} and {Resolved, Closed}. In Jira, an issue is "open" if its status is in the set
{Open, In Progress, Reopened}
and an issue is "resolved" if its status is in the set
{Resolved, Closed}
Work tasks that are Not Done are the tasks that are in our sprint backlog and that appear as unspent hours on our sprint burndown chart. We want Jira's default filters and reports to tell us about these issues--the ones that are Not Done (not Resolved or Closed)--but the way developers use Jira, Resolved doesn't mean the same thing as Done.

In its default configuration, Jira is a code writer's tool. Its default filters and reports reflect the code writer's perspective of task completion: if the developer wrote the code, his unit tests passed, and he committed the code, he marks the issue Resolved/Fixed. When he marks an issue Resolved, it is no longer "open" and it disappears from the default filters and reports. Examples of these filters and reports are the issue counters on the Browse Project page, the Components and Versions filters, and the Version Workload Report. That Jira's Resolved is not the same as the team's definition of Done makes it difficult to use Jira to track which issues are Done and which are Not Done; it is difficult to use Jira to track sprint backlog and burndown. Jira's Resolved is not equivalent to the team's definition of Done.

Yet Jira is an excellent tool for tracking issues and organizing work tasks. We use Jira to organize our product backlog, release backlog, and sprint backlog. Because we rely on Jira, we need the default Versions filters to show us which issues are Not Done yet in each backlog. We need the default Version Workload Report to show us how much effort estimate remains in our sprint backlog, so we can keep our sprint burndown chart up to date. How can we reconcile Jira's focus on the individual developer with our need for a team view of Done?

We solve the problem by creating a custom Scrum workflow. Our Scrum workflow has a new state, In Verification & Validation. Semantically, this state is a different kind of "open" or Not Done. Now, an issue is "open" if its status is in the set
{Open, In Progress, In Verification & Validation, Reopened}
We add transitions to and from In Verification & Validation to support the new workflow. When a developer thinks he completed his part of an issue, he clicks Ready for Verification to mark it In Verification & Validation, and the rest of the team knows it is fair game for testing. We mark an issue Resolved/Fixed only when the team as a whole thinks the issue is Done.

Team members can now communicate different kinds of Not Done to each other through Jira, and Jira's default filters and reports still work. The Components and Versions filters correctly show the issues that are Not Done, and the Version Workload Report accurately shows remaining burndown. Problem solved, and Jira is our friend again.







2 comments:

James said...

Nice review of using the workflow!

We had the same conversations regarding "done" when we moved to Jira. We decided to make a team process to handle that. If an issue is resolved, it is ready for testing, and if has been tested good it gets closed. Not very intuitive though I agree.

We did add a step in our workflow called "Waiting on Issue". It is only available if you have a link to a "depends on" issue or if you have a sub-task. If all the sub-tasks and linked issues that you are dependent are resolved then the issue automatically jumps from "Waiting on Issue" to "Open" and the assignee gets notified.

James said...

Nice review of using the workflow!

We had the same conversations regarding "done" when we moved to Jira. We decided to make a team process to handle that. If an issue is resolved, it is ready for testing, and if has been tested good it gets closed. Not very intuitive though I agree.

We did add a step in our workflow called "Waiting on Issue". It is only available if you have a link to a "depends on" issue or if you have a sub-task. If all the sub-tasks and linked issues that you are dependent are resolved then the issue automatically jumps from "Waiting on Issue" to "Open" and the assignee gets notified.

LinkWithin

Related Posts with Thumbnails