Our backlog is stale. Most old tickets are no longer critical. Either handled or no longer critical because sites’ needs have changed, or no longer makes sense on current version of OMRS.
We need a better process. Even if we started with 0 issues right now, we’d end up in the same place later, if we don’t have a consistent way of addressing the backlog. Many tickets sit in a “maybe we should do this someday” state. Makes it difficult to prioritize and talk about / see what we’re actually working on as a community.
The many-step workflows are painful. It’s difficult to transition an issue through the many steps, so it’s hard for our community to collectively keep things up-to-date together.
Our Goal
An issue tracking system that clearly shows what’s important and what’s ready to work on, and is easy for the community to keep up to date.
Here’s what we’re doing about it
Immediate Jira Cleanup: Meeting ~ 1x/week to clean up the backlog (like was mentioned here), so that we can focus our attention on the more recent requests that are more likely to still be important. We’ll likely be applying rules like “if a ticket hasn’t been updated in >4 years, cancel the ticket”. Anyone is welcome to attend these; they’ll often be during Design Forum times but I’ll post in advance so people know when to join.
Monthly Backlog Reviews: We’ll schedule a monthly time (open to anyone) where we’ll go through the more recent backlog of tickets, to do more clean up and triage.
Standard Workflow Change: With community consultation, we’d like to simplify the workflow steps of tickets, and make it easier for people to keep the ticket status updated - so we can keep our Jira up-to-date together as a community!
Adjusting the workflow would always look like this, and anyone would be able to adjust the ticket as long as they are logged-in to their Jira account:
We’d host community training sessions about the change. Squads would be able to configure the workflow if needed, but we’d all share the same simple starting place.
What you can do!
Help clean up old tickets you’re familiar with: Review any tickets assigned to you or created by you in RA or TRUNK, and close or cancel old ones that are done or no longer relevant. Use this link (and make sure you are logged-in). Let us know if you run into permission issues.
Share your feedback on the workflow: What do you think of the proposed Simplified Workflow? Let us know in this thread!
IMO I think we need to focus on more concrete steps to communicate what needs to be done, so I am suggesting:
Backlog (starting state) - everything goes there
In Analysis
In Design
In Progress
Under Review
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
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:
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.
What step would tickets go to if they’re ready for dev work? This was the reason for the To Do step.
@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
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)
@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?
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
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).
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.
@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
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.
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.
After assessing, a ticket can be properly curated and made ready for work. READY FOR WORK
Some tickets need more clarification from the creator. WAITING ON INFORMATION
A ticket has been picked up by some one who is working on it. IN PROGRESS.
A pull request has been raised and hence waiting for review and merging. INITIAL CODE REVIEW
Has been committed or pull request merged, but waiting for another pair of eyes to review, before we can close. POST COMMIT REVIEW.
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.
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.
