Skip to main content

Kanban: How to visualize minor support tickets with Jira

Last post 01:43 pm April 10, 2020 by Timothy Baffa
7 replies
02:29 pm April 8, 2020

Hey everyone,

I am working with a heterogeneous IT team (2x dev, 2x analyst, 1x qa) and lately we switched to Kanban. Everyone was in a good mood and looking forward, especially our Analysts who found themselves way more represented in our daily stand-up, now. We made a commitment to make a ticket for every support task which takes 2h or more.

My topic to discuss is: How to visualize tickets which will be solved in less than 2h without creating too much overhead.

In the analog world I could find plenty of options but actually we are all bound to homeoffice and we don't have a real board anymore. We are using Jira and they might be not so happy with using another tool. Maybe Jira will not be the answer and there will be a way to keep it simple and, as far as possible, effortless. But I don't see it, yet. 

Looking forward to discuss and share it with you!


04:58 pm April 8, 2020

especially our Analysts who found themselves way more represented in our daily stand-up, now

First thing that pops into my mind is; did you need Kanban to get to this??

We made a commitment to make a ticket for every support task which takes 2h or more.

Hypothetically, how would you visualize and make transparent if your sprint was actually made up from 200x 1h tickets?

My topic to discuss is: How to visualize tickets which will be solved in less than 2h without creating too much overhead.

Overhead in my view in Kanban is minimal, so even an 1h task can be made visible though the entire flow taking only seconds.

we don't have a real board anymore

There are amazing good online boards for this!!

not so happy with using another tool.

Isn't the physical board also not just "another tool"? Why would an online board be different?

 


04:59 pm April 8, 2020

Maybe I did not underatdn correctly, but Jira itself has also the ability (I think with some plugins) to be configured as kanban tool


12:59 am April 9, 2020

What do you consider a support task? Can you provide some examples of what type of work would be considered a support task?

What tools are you currently using to track tickets? Any ticket entered in Jira should be able to be visualized on a board, so I don't fully understand what overhead exists if tickets are already entered for the work. It's not clear if all work is represented by tickets or if only work that requires 2 hours or more requires a ticket.

Where did 2 hours come from? Was the team involved in making this decision? Did the team look at previous work to see how much work was more than or less than 2 hours to see what the impact of this level of granularity would be?


07:41 am April 9, 2020

Hello Xander and Thomas,

thank you for your replies.

No, it didn't need Kanban to represent our Analysts. With Scrum and sprints everything was just more based on developer tickets to reach the sprint goal. 

We have a jira board with wip limits and columns that fit our needs. So we do have a board and we are using it for our dailys. Being back in the office we would do something like the "task snake" (bring a post-it on the board for every solved support task to visualize how much work our supporters are doing). They want to take part, not "just" verbally, its like they want to play the game just like our devs and our qa and as it seems to make them more satisfied (and their work more transparent) I want to provide them a method to do so.

The 2h limit was defined by the team and we use our retros to check if it should be higher or lower. A usual support task can be to update datasets on the database or start a batch on demand. We still have a way to go with how support tasks will be communicated towards our team (and other teams around - the mindset has yet to change). Currently our inhouse client is using all kinds of ways, so there is no option like automatically created jira tickets (which I would prefer) or sth like that. They just don't want to do a ticket, from hand, for every task that took them like 5 minutes and I can understand that. But they want to be seen with what they have done, they want to be integreted, task wise, and I want to have them on board (literally) to identifiy where the problems and challenges are.

This whole challenge wouldn't be there, if there would be a unified way to adress support tasks and maybe even automatically convert them into jira tickets. Maybe I should continue to stick on this vision :-).

~Jan


08:24 am April 9, 2020

My topic to discuss is: How to visualize tickets which will be solved in less than 2h without creating too much overhead.

Does your team have a Kanban policy of accepting work that is not ticketed?


10:47 am April 10, 2020

Hi Ian,

yes, actually they have this policy. To make it a bit more complicated we have a second tool (historically grown) which makes up the interface between IT and client, so our client create tickets within this second tool but our IT is working with jira. But that affects support tickets only, dev tickets will be created in jira. I am not in the position to change that but I stay on repeat to recommend so.


01:43 pm April 10, 2020

We made a commitment to make a ticket for every support task which takes 2h or more.

To echo Xander's question, how would you radiate information if your team only worked on items which took less than 2 hours?   I'm also assuming that the team is providing the estimate, hopefully based on similar efforts in the past?



Why the artificial constraint around more/less than 2 hours?   Wouldn't the problem be solved (and all work done by the team visible and radiated to anyone interested) if all work was submitted or copied into a Jira item?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.