Thoughts on Tickets
Make your ticket process as simple as possible.
Tickets are the lifeblood of any software company. At any point in time you are going to have a priority queue of different bugs, features, and other urgent things that need to be fixed ASAP.
So what should the general bug/feature process look like? In my view, this needs to be as simple as possible. Tickets get put in a backlog. The backlog is like an inbox – your goal should be to get to "backlog zero". From the backlog, tickets can get moved into a couple different buckets which basically boil down to "No", "Maybe", and "Yes".
- No = "Won't Do", "Duplicate"
- Maybe = "Needs Info"
- Yes = "To Do"
Below is a simple directed graph highlighting how things should work.
First, any ticket for both bugs and features are going to go into a backlog. From there, someone in Product/Engineering needs to triage this list with input from both the pre- and post-sales organizations.
Right off the bat, there are a couple different things that can happen:
- Won't Do: Sometimes there are things that can't/won't be done. It's not personal. Maybe it's a bug is related to a previous version or it could be something that is simply not in the scope of the product. If it isn't something that an Engineering/Product/Design can or will tackle, it is something that EPD "Won't Do".
- Duplicate: This one is easy. If a ticket is one that has already been filed it's a duplicate and should be consolidated with the ticket that already exists.
- Needs Info: Here you have a ticket that doesn't have enough information to make a determination about next steps. It could be that you need to flesh out the use case. It could mean that you need more information about expected behavior from the current (or proposed) feature. It could be that you need to refine exactly what the issue is. Point is that there simply isn't enough information to determine what to do next. Once there is more information, this can go back in the backlog.
If there's a sufficient amount of information in the ticket, the use case is clear, and people agree that it's something that is valuable, then the ticket can be moved to To Do. This is essentially a placeholder for things that EPD could be working on.
Every engineering org has a different bug/feature development process. Moreover, Engineering/Product/Design tend to be very opinionated about how this process ought to work, which is why I've left it as a green box. Finally, once things are completed and tested, they can be considered Done.
Again, the goal of this is not to create process for the sake of creating process. What it does is aligns the org about next steps which is critical for maintaining forward momentum.
If there are any engineers out there who have a detailed breakdown about what should happen after the To Do section, I'd love to hear from you!