Why do I need more than one done status in my workflow jira cloud

PATRICIA MURPHY

Do we really need more than one done status? Has anyone faced this before and come up with a solution?

 

Teams want a done status of accepted when they finish their work on a bug BUT the rule is the creator/reporter of the bug has the final acceptance vote for done/done. The team wants credit for the work they did to get it to their definition of done. There are two solutions proposed.

1. The creator/reporter opens bugs directly to the team that should fix it.

• The team wants two done statuses in their workflow, Accepted = the team is done and has met their DoD and they get there points in their sprint but it is not really done/done until the creator/reporter moves the issue to the final done state of resolved.
• In this scenario we have issues, crossed through, accepted that are done but not really done.
• Users from other parts of the org recognize the key strike through and the status of accepted as done/done, no more work is happening on this item.

 

2.  An "epic" (or =work item type) be used by the creator to open the initial defect. Under this "work item" a child bug is opened and assigned to the team that will fix the bug.

(**Note we would also like creators/reporters of bugs to open bugs directly against teams but we have 12 new development teams so most times it is hard for the reporter to know which team should actually fix the bug so we propose, at least short term, one project where all bugs are opened and screened out to the specific teams)

• The team discovers they also need another team to work on the bug then they open a child bug under the parent for the other team.
• The team(s) works the child bug(s) until it meets the team(s) DoD and accepts the bug. The team gets their points.     
• Via automation the status of the parent/original work item status stays updated and like epics all children can be seen under the parent.
• Once all children are accepted within their teams the parent moves to completed. Now it is up to the creator/reporter to accept the work in the parent work item.
• If the do not accept the work they move the parent back to in progress and open new child bug(s) for the teams(s) to take another run at fixing it.

Trudy P Claspill

Hello @PATRICIA MURPHY 

That is an interesting dilemma.

The first thing I would question is the concept that the development team can consider their work "done" if the group that opened the bug has not yet accepted the solution. How do they know that their work is actually completed if the reporters have not accepted the solution? I think it would be worthwhile to explore that a bit more.

Disregarding that...

 

I have some questions about the projects used by the developers:

1. Are they using Company Managed projects or Team Managed projects?

2. Are they using Scrum or Kanban?

 

In your first proposed solution the issues get a strikethrough when development has reached their DoD, but the team that opened the bug has not accepted the solution. Is it a problem that the issues get a strikethrough?

If so, you could eliminate that by having a status such as "Waiting for Acceptance" that is assigned to the "In Progress" Status Category. You would not set the Resolution field during these transitions. The development team would set the bug to that status when they reach their DoD. That status would be mapped to the right-most column of their board.

You would also have a "final" Done/Accepted status that would be part of the "Done" Status Category. Transitions to this status would include setting the Resolution field. The status would also be mapped to that right-most column. You could set a Condition on the transitions to that Done/Accepted status so that the developers could not transition issues to that status.

If you are using Scrum, then issues in the right-most column of the board are considered "complete" at the end of a sprint, so the developers would get their credit for their work being done as they move the issues to the "Waiting for Acceptance" Status. The issue would not have a strikethrough at that point. The strikethrough would not happen until the issue was transitioned to Done/Accepted.

A side affect of "Waiting for Acceptance" not getting a Resolution value would be that any filter or report based on an issue being "resolved" would report these issues as "unresolved". Dashboard gadgets like the Created vs. Resolved report would not count the "Waiting for Acceptance" issues as Resolved.

 

Are there any other processes tied to the issue getting a Resolution and moving to the "accepted" state that need to be considered and still need to be applied when the issue is "waiting for acceptance"?

 

The above modification doesn't address some of the other challenges you try to address with the second solution, such as knowing what team is responsible for fixing the bug or what to do when multiple teams need to supply fixes for a bug.