• some guy (unregistered)

    To be fair, it at least used to be the case that the diagram could be unspaghettified manually, resolving at least the display issue. That does not solve the problem of "PM putting in an absurd workflow that nobody understands", which leads to circumvention and lack of actionable data.

  • Greg (unregistered)

    I think you mean "sluiten" instead of "gesloten". (sluiten = to close; gesloten = closed)

  • Officer Johnny Holzkopf (unregistered)

    This friendly flowchart will help you in every business situation. It's worth being printed in A0 format to enlighten the whole office. But beware of the automatic sprint bug of Klaar. Now sit.

  • Spiffy Voxel (unregistered)

    That is less a flow-chart and more a chaos-chart. If someone handed me that, I'd have to suspect either a prank or the creator needs help, possibly of the psychiatric variety…

  • Agile guy (unregistered)

    I would root for 3 states. Open -> In progress -> Deployed

    All other states can be collapsed to those 3. And rather focus on the lean principles,

    • WIP
    • reducing waste
    • short feedback ...
  • No (unregistered)
    Comment held for moderation.
  • Darren (unregistered)

    "Developing software can't simply be done with a text editor and a compiler"

    Yes, it can. Whether it's easy to do it this way is a different questions, but there were decades of development where a text editor and compiler were all that was available.

    I'd even ague that for a lot of simple projects it's probably the best / easiest way to do so.

  • (nodebb)

    The question is, is the team's actual workflow—the way they really do the work—equally complex?

    I've used Jira for a few decades now. When used properly, it's a great ticketing system. But "properly" starts with "the workflow matches the way the team actually works." The very first thing one should do before adopting Jira is make a flowchart of how your team actually processes work. Then you can build statuses and transitions that match that flowchart, and your team will find Jira comfortable because it works the way they do.

    This may mean that you wind up with a whole bunch of ticket types and projects to wrangle different workflows, but guess what? That's your own processes that are "inefficient," not Jira. And maybe they're not "inefficient" so much as "necessary given the circumstances"...

    When I see people that despise Jira, it's usually because their employer decided that everyone must use The One True Workflow that matches absolutely nobody's way of working, and so everyone's interaction with Jira is a bunch of manual workarounds and kludges to try and make The One True Workflow match what they do. That's TRWTF.

  • (nodebb)

    Jira reminds me so much of Lotus Notes.

    I was in a place that used Notes for email once upon a time, in the early 90s. It was slow. Glitchy. Impenetrable.

    The problem was that Notes/Domino wasn't really an email platform, it was a client/server programming system for text and data sharing. The primary application built on it was a bad email system.

    Among other problems, the hardware of the day couldn't keep up with the software's demands.

  • (nodebb) in reply to macwhiz

    Many, many software teams don't really have a single workflow, because often the ad-hoc problems they solve don't all fit in the same envelope.

  • Scragar (unregistered) in reply to Agile guy

    Youecategories have a few holes(like if a ticket is rejected, or the requester changes their mind).

    Therefore I suggest 3 different broad categories:

    Needs Work - for anything no one is working on that needs work In Progress- for anything someone is working on Closed - for anything that needs no more work

    Although honestly every company I've worked at has had the same basic flow once it hits dev: Planning(breaking down work and adding estimates) -> backlog -> approved for sprint -> in progress -> PR review -> awaiting deploy -> ready for test -> test passed -> done

    If I was to make a ticketing system I'd start with this and make sections skippable with alternative options available, but the core will generally be similar to this flow so why not make it the default flow?

Leave a comment on “The State of Ticketing”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article