Jira Improvements Update: Your feedback wanted

IMO I think we need to focus on more concrete steps to communicate what needs to be done, so I am suggesting:

  1. Backlog (starting state) - everything goes there
  2. In Analysis
  3. In Design
  4. In Progress
  5. Under Review
  6. Closed/Done

The reason really is that some tickets are blocked because they require more analysis and design, but backlog does not communicate what work needs to be done to move the ticket forward.

In Progress should actually mean that development is happening, rather than either analysis/design which leaves tickets ambiguous

2 Likes

Thank you Stephen for this thoughtful reply. Your comment makes a lot of sense, and very much agreed that Backlog should be the starting state. Two follow-up questions:

  1. What would be the main difference between In Analysis and In Design? It seems like many work requests don’t need to go through UX, or even deep technical discussion, so I wonder if we could combine these with something like Requirements in Progress (that’s an ugly name but that’s the jist). You’re right that we need to better capture this phase, so long as we try to keep things simple.

  2. What step would tickets go to if they’re ready for dev work? This was the reason for the To Do step.

1 Like

@grace Excellent questions, thinking about it again, I would replace in In Design with Ready for Work

Most “current” tickets may seem to be small fixes which IMO is a “bad smell” which means that there is no deep work is being done that is requires more detailed discussion on implementation approaches, design etc.

The steps look many, however the longer term picture is clarity and explicit visibility into what the needs are. Shorter steps always mean that there is more to what meets the eye

3 Likes

So i would want to combine ideas from @ssmusoke and what @grace has proposed and come up with some thing like

  • Backlog
  • In Analysis
  • To do /Ready for Work
  • In Progress
  • PR Pending
  • Under Review
  • Closed/Done
2 Likes

Thanks for bringing this @grace, personally i think since this is a click per say,we don’t need to hide some work flows .i haven’t seen much effect with the former jira workflow both RA and TRUNK. however i would also think like this

  • Backlog
  • In Analysis
  • TODO(though we are trying to hide ready for work/waiting for dev)
  • In progress
  • Under Review
  • Accepted
  • Closed/Done

IMO

@mozzy Awaiting PR does not make sense, since the output of In Progress is a PR or it goes back to Ready for Work. The states have to be verbs, TODO is one of the most ambiguous of them all

@sharif I do not understand why you are trying to hide ready to work for dev. What does TODO mean? What state is that?

2 Likes

Was trying to mean that if we apply TODO in both TRUNK and RA we are hiding ready for work and waiting for dev respectively, May be if TODO is going to be included on one side of either TRUNK or RA

makes sense ,

I think JIRA’s simplified workflow should be the default for all projects, so people can make whatever columns they want/need in a board view.

The challenge is a simplified workflow assumes people know & follow compatible workflows (i.e., states are intuitive or well-documented). The one advantage of the proscriptive workflow we have now is that it helps devs by providing well-named transitions that become buttons in the UI (like “Claim ticket”) that just do the right thing.

Could we have our cake & eat it too? Is it possible to use JIRA’s simplified workflow so people can make & adapt boards without separately managing the workflow definition AND add in a few key/helpful transitions without messing up the simplified workflow? Then we could still allow all states to go to any other, but supplement specific transitions (like “Claim ticket”) that would add buttons in the UI to guide people through the common transitions.

I’m not sure you’ll be able to find the “perfect” set of states. There will always be a good argument for adding or removing states. We know we need “Backlog”, some form of “Ready for Work”, something like “In Progress”, and an end state like “Done” or “Closed”. The rest will vary. Coding projects (like most of ours are) would benefit from a “PR pending”. Then, as @ssmusoke points out, the number of states can grow based on needs (e.g., How many tickets are blocked? How many need design help? Do we have a separate state for acceptance testing? Some projects really wanted these and others don’t want them).

2 Likes

I actually have the opposite take on this. Jira tickets / cards / issues are not really an ideal space for design discussions. We should utilise other forums, like Talk and design calls for those discussions. Something should only be raised as an issue, in my view, when work can actually be done on it.

I do agree that there are some uses of our Jira system that seem to be generating more tickets than we may perhaps need, but that seems to me to be a separate issue from what we’re trying to address here.

2 Likes

@ibacher Actually what I meant is that the tickets are a single source of truth for all work done, even if discussions are held in other forums

Too few tickets that need analysis and design means only tiny tweaks and enhancements are being done, and nothing is deep is moving the platforms forward since platforms need major additions every 2-3 years

3 Likes

These are the states i have been going through while traversing JIRA tickets. You can ignore the names of the states or even call them something else.

  1. The state of tickets that have just been created by some one and require attention or assessment. The assessment could result into something as simple as, was fixed some time back in a particular released version, is a duplicate of some other ticket, etc. NEEDS ASSESSMENT.

  2. After assessing, a ticket can be properly curated and made ready for work. READY FOR WORK

  3. Some tickets need more clarification from the creator. WAITING ON INFORMATION

  4. A ticket has been picked up by some one who is working on it. IN PROGRESS.

  5. A pull request has been raised and hence waiting for review and merging. INITIAL CODE REVIEW

  6. Has been committed or pull request merged, but waiting for another pair of eyes to review, before we can close. POST COMMIT REVIEW.

  7. All is well and ticket is closed as fixed.

3 Likes

Coming back to this now. I continue to see teams/squads losing, on average, at least 20-30 mins per team of peoples’ time in calls every week just from fiddling with workflow states.

Based on the feedback above, here’s what I propose - I’d like to make this update in 1 week to the RA and TRUNK projects at least - it’s high time.

  • Needs Assessment
  • Waiting on Information
  • Ready for Work
  • In Progress
  • Code Review (Initial)
  • Code Review (Post-Commit)
  • Cancelled
  • Done

Yes, it’s possible, but can we first try using these simpler transitions? If we think the state names aren’t clear enough, then I think we should change the state names, rather than adding more Jira workflow overhead.

I would like to include one special screen: When you close an issue, we should get them to confirm the Resolution and the Fix Version. But that’s it. Anything more is too complex.

Demo

Here’s the impact. Imagine you want to move a ticket through states in the RefApp project right now.

Current Experience

Updating a Ticket with OLD Jira Workflow

Proposed Experience (It’s so much faster!)

Updating a Ticket with New Jira Workflow

CC @dkayiwa @ibacher @ssmusoke

1 Like

Thanks @grace ,how about approved status, we seem to be loosing track in qa jira board

Please also include FM2 in this as well! Be very glad to see a much simplified workflow process.

1 Like

Thanks @grace this works …

1 Like

Do you mean approved as in “ready for dev work” or as in “done”?

Done probably

OK I see. So that would be covered by the “Done” status. If folks wanted to indicate that the work had been merged but they want someone to have another look, they can put it into “Code Review (Post-Commit)”, then later we would mark it as “Done”.

What’s the problem you’re seeing in the QA team example?

1 Like

We reviewed this in the TAC and PM Team today. The agreement is to proceed, with a few caveats:

  • “Claim Issue”: there should be a workflow that enables users to click & assign themselves (if they’re not accustomed to using Jira to change the assignee to themselves directly)
  • Modal for “In Progress”: Ask who the assignee is
  • Modal for “Done”: Request the user confirm the Resolution result (e.g. Fixed, Won’t Do) and the Fix Version.

I’ll try to execute these changes tomorrow.

1 Like