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
TODO(though we are trying to hide ready for work/waiting
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.
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.
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?