One of the things that our team has struggled with the most is providing our development teams with quantifiable data for user feature requests and annoyances (e.g. UI/UX issues).
We noted that this was something that the problem/incident flow did really well when we were presenting a case for bug fixing. We were able to say we had 47 incidents etc. However, there was no obvious way to duplicate this flow. With a bit of assistance we've managed to succesfully replicate this system and it's really quite simple.
1. You'll start by adding a custom field to your tickets (we used a drop down menu labelled "Issue type") that includes any category you'd like to track using this method. As noted we've used "feature request" and "annoyance".
2. We then created two additional views for our team, one for each respective category.
The views themselves are specifically designed to show problem tickets with the custom categories and exclude the traditional problem ticket.
We achieved this by setting up the following under the "meets all conditions" sections in our view:
- Ticket: Status is less than solved
- Ticket:Type is problem
- TIcket: Issue type (our custom field) is "annoyance".
3. We adjusted our original "problem" view by ensuring that the "meets all conditions" section includes
-Ticket: Issue type (our custom field) is not annoyance
- Ticket: Issue type (our custom field) is not feature request
It's as simple as that, you can now duplicate the problem/incident flow for any number of categories and therefore, get good quantitative data for feature requests that enable you to put more weight behind requests to your development teams.
Note: The only potential downside of this is tagging incidents as all of your problem tickets will be included in the problem list when looking to pair an incident to a problem ticket. As these come with a search feature this wasn't considered a big deal for us however, if you're accustomed to a fairly small list of problems it's something to be aware of.
Hope this helps!
댓글을 남기려면 로그인하세요.