Thomas Carney on November 26, 2015 Principles and Processes for Smooth Issue Tracking
A well-organized issue tracker will make it easier to handle issues that arise in your company.
Issues such as customer support requests get lost in a sea of email. That’s where issue trackers step in.
They let you track an issue from creation to closure. It makes it easy to move an issue from person to person. It also reduces the chances of an issue slipping through the cracks.
Here, we’ll dig into some principles that will help you figure out what’s the best way to set up your issue tracker, and then we’ll tackle how you can create a custom workflow that works for your situation.
Push Processes vs Pull Processes
In a push process, someone will be constantly assigning issues to others. As an example, you might stumble across a bug in your software. You’ll open up Planio, create an issue for the bug and then assign it to someone else on your team.
This is an example of a push process: you’re pushing work on someone!
The second type of process is a pull process. A user might add an issue into a general backlog of issues.
Team members working on those issues will grab an issue, mark it as assigned to them and start working on it.
You can add fields such as priority and due dates to issues to help the team decide which issues should be dealt with first.
If your workflow is based on a pull process, it can be very handy to have tight integration between the issue tracker and email.
For example, in Planio you can set it up so you can send an email to support@example.com, and the email will end as an issue in a project in Planio.
When is “Done” in Your Process?
Getting to “Done” is not as simple as it might seem.
When you’re a developer, you might feel that you’re done when the bug has been fixed, whereas a customer support person might consider done when the customer feels their problem has been resolved.
You don’t want a situation where issues appear to have been resolved, but in fact there is still work to be done on them.
Find the actual state of ‘done’ in your process, and you’ll be able to track your team’s rate of work and work in progress.
That will let you know whether you need to bring in more people or reduce certain types of work.
Open or Restricted?
You can make sure an issue goes through a certain order before being resolved. For instance, a junior support person resolves the issue, a manager reviews it, and then the solution is delivered to the client.
The opposite situation is where you have an open process. Anyone can move issues freely between various statuses.
A junior person can then re-open a closed issue if they feel it hasn’t actually been resolved.
Your decision will depend on the internal company culture and the level of review you need.
Now, let’s apply these principles to a specific example.
The Four Magical Steps to Crafting the Perfect Workflow in Planio
1. Sketch the Process.
Grab a piece of paper and literally sketch out a common process on a piece of paper. Label each of the steps between them, showing how an issue can move between various states. This will give you a good idea of how the above principles apply to your process.
2. What information will you need?
Let’s imagine that the issue in our process will be a bug in our newly released Schnitzel Finder app. Irate users will create an issue reporting a bug.
The development team needs certain information for the bug. They want to know the steps the user took that caused the bug, what the user expected and what they got instead.
They’ll also need information on the device the person was using.
Therefore, we can write out the fields that the user will have to fill in. We’ll create some custom fields for the OS, so the Android team can create a filter just for bugs on Android devices.
Then, we can write down the various statuses a bug could have:
- New
- Verified
- Rejected
- In Progress
- Testing
- Fixed
3. Plan the various transitions
Finally, we can decide who can do what.
Obviously, in our example, a user can only do one thing: create a new bug. They can’t move it to any other status. A developer can verify, reject or work on a bug. A QA specialist might be able to test it, and finally move it to fixed.
In contrast, in a public open source project, anyone might be able to move an issue to any status.
4. Put it to the Test
Now that you’ve defined the workflow, it’s time to put it to the test.
You can set up the workflow in Planio and create a few sample issues to test your approach.
Here’s a guide on the specifics: Create a custom workflow for recurring tasks.
We now have a workflow that’s perfectly suited to our team. We’ll be able to ensure consistent quality even if the team gets larger as new people join.
They’ll be able to start getting work done faster, because they have a system to follow.
Happy issue tracking!
