Request for a "Dropped" StatusCategory (or the option to define my own StatusCategory)

[Brian Debler]

All of the workflows I manage have a "Abandoned", "Dropped", or similar status which lets the team know that the described work is no longer relevant to the project.  To prevent these Dropped items from moving into the next Sprint, I treat the Dropped state as part of the "Done" statusCategory.  It's not a really great solution because without some automation and care in reporting, it can easily look like the work that the team quit working on it actually finished rather than being halted.

This led me to wonder if there would be interest in a "Dropped" statusCategory so I can differentiate between work that is completed and work that is no longer going to be worked on but was not actually accomplished.

The idea would be to treat items in a StatusCategory of Dropped as done for purposes of carrying them over from one Sprint to the next, but flag them with a unique color (like black) so it is clear they were not actually completed.

This also led me to wonder if there would be interest in options to define your own StatusCategory for further workflow management without being as tied to specific Status.  That may be more of a niche option for Jira users, but it is still one I could see being useful for someone like myself who wants more classifications to assigning Status to different StatusCategory options.

[Laurie Sciutti]

Hi @Brian Debler ~ this sounds more like something you'd want as a Resolution (like "Won't Do").  What are you currently using as the Resolution for these?

[Brian Debler]

Yep, a "Won't Do" StatusCategory would be great.

The main thing I would use such a Resolution for would be to exclude the work from moving forward into future Sprints and exclude it from reporting.  Visually, showing such items in a black (instead of green) would help stakeholders understand when work is not ever going to be done better.

If I had this as a StatusCategory I could add further Status values to better describe why the work will not be done ever.  It would be nice to better capture when we drop work because it doesn't fit with the updated product vision as opposed to dropping it because we learned the work couldn't be accomplished as we wanted it to and we need to change direction to something else.  I could add these states currently, but then I need to add specialized handling for "status in (Dropped, Abandoned, Rejected, etc, etc)", and when I need to add a new Status I have to update it in a bunch of places.  And then items with these Status still show up visually in the same way as Completed work.

Overall, this is a minor quality-of-life upgrade for me, but it also seems like a minor effort to apply as well.

[Bill Sheboy]

Hi @Brian Debler 

As @Laurie Sciutti was noting, perhaps you are blending some Jira terminology, and the Resolution field would be better.

• Issues have a Workflow (i.e., a process shown as a state diagram), compose of a series of Status values
• Each Status has a Status Category value, with one of the following: To Do, In Progress, or Done.  The power of the Status Category is it allows summarizing the status of issues spanning different workflows with different Status values, even across Projects.
• An issue may also have a Resolution when it is completed.  Think about defects, where many could be in a "Done" status, but have different dispositions communicated with Resolution: "fixed", "not a defect", "cannot reproduce", "won't do", etc.

Changing Status Category in Jira would likely be quite a disruptive change.  I recommend trying to use the Resolution for what you describe.  Perhaps discuss this need with your Jira Site Admin to get their input.

Kind regards,
Bill