Comment by teeray
I also loved that it was adamant about having specific, defined states with no customization. The issue is todo, in progress, done, delivered, accepted… that’s it. Custom issue states are a special kind of hell in JIRA.
I also loved that it was adamant about having specific, defined states with no customization. The issue is todo, in progress, done, delivered, accepted… that’s it. Custom issue states are a special kind of hell in JIRA.
For the article:
> Whilst I wouldn’t recommend remote team members having to endure a subpar experience, for example during the daily Kanban meeting, is that really a good reason to degrade the experience for the rest of the team, losing out on all the benefits that gathering around a physical board can bring?
Are they seriously proposing _physical kanban board_ as a viable alternative to JIRA? This got to be a joke, right?
(Checks post date, it's 2019... Ah, that explains it)
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.
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.
A model that 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.
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.
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.
> 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...