> Custom issue states are a special kind of hell in JIRA.

The nth circle of hell looks like a Jira workflow. https://i.imgur.com/dQE9vWn.png and https://medium.com/@daitcheson/you-can-do-better-than-jira-1...

Your honor, he needed killin’.

[delayed]

Worked with a manager who had a physical kanban board in a nearby vacant cube... and had a ip camera set up to it so that the business could go to the IP and see the board. When they had meetings, they'd have the business people on speaker phone and... honestly, we had trouble not laughing overhearing those meetings.

That first one looks kind of reasonable compared to our ‘simplified’ workflow. The full one?…

That fucking state machine page makes me want to shoot someone.

Yes - 100% of the people I saw be annoyed after switching to GitHub projects were the people whose projects were perennially late but also had a roughly 1:1 ratio of PM overhead rituals to actual work. I’ve come to think of it like giving a toddler TikTok – there’s a certain type of person who cannot resist thinking that one more workflow state / custom field will be the secret trick for productivity.

60% yes, but 40% no, because there was nothing after "accepted" - so no way to track "in production" and "validated with users", which are the most important states. You could abuse the earlier states to do that, but then you have trouble tracking internal acceptance. Ultimately, reality just has more significant states than Tracker recognised.

What has worked well for my teams is to track story/development state and deployment state separately.

They are fundamentally different things, and you cannot always infer one from the other.

  - "Accepted" is the final state. Deployed to prod and verified. Story is finished and can be hidden from active view.

  - "Delivered" is set by QA when they believe the changes are complete and correct, ready for deployment.

  - "Finished" is set by the developer when they finish, push, and create the PR.

Then we use labels for deployment state. E.g. @staging, @sandbox, @production, etc.

It happens sometimes that a Finished story is deployed to staging in integration build X, but then omitted from integration build X+1, for reasons unrelated to the quality of the changes. In this case the story stays Finished (or Delivered) and we set the @staging label when deploying X to staging, but clear it when deploying X+1.

This works really well, especially after writing some glue code to integrate Pivotal and GitHub and your build/deploy flows.