Please help me understand the difference between sprint/kanban and queue

[Mrinal Mondal]

Hi,

I am trying to understand the difference between Jira Sprint/Kanban framework and the Jira ServiceDesk queue. I am planning to migrate my old data from Jira to Jira ServiceDesk and looking for a list of which I should think/plan before initiating the migration.

[Nic Brough -Adaptavist-]

Welcome to the community!

That's a very very long essay, but a very very short getting-started might be:

All of these things deal with a stream of incoming items of work that need some form of attention and probably action.  The grouped name for these items is "issues" in Jira, so that's what I'll use here.  

The items/issues could be coming from anywhere, and frankly it doesn't  really matter too much, but some examples would be:

• requests from users raising them in a help-desk
• stories from product owners and people wanting new stuff
• alerts from monitoring systems
• questions from people
• action requests (tasks)
• and and and ...

All three things are different ways to handle streams of incoming issues.

• A sprint is a time-box, during which time, a team commits to delivering a number of (sized) items.  (There's a lot more to it, but the main thing here is "timebox for delivery of agreed items"). 
  • The board is a very visual way of tracking things as they move through the development process during the sprint. 
  • The development team choose what to put into a sprint, and what order to do them in during a sprint.  The dev team and the product owners prioritise the backlog (stuff to go into a sprint next). 
  • Stuff is measured by the size of the items delivered (or not)
• A Kanban is similar, in that there is an influx of issues arriving, and a team tracks where each one is in the process with a board. 
  • There's no time-boxing though, you just keep taking cards from the to-do list and moving them across the board. 
  • The team also prioritises the incoming issues, usually with some simple business rules to help do most of the work, and the team is always expected to take the highest priority issue next
  • Stuff is measured by throughput, not effort or size
• A Queue is more "drinking from the firehose"
  • The issues are prioritised by the rules set up for the queue, with little human intervention, and the team always takes their next item from the top of the list.
  • Stuff is measured by mostly business based rules - Service Level Agreements

Sprints (scrum) are mostly associated with iterative development work, Kanban is a bit more operational, and queues tend to be used mainly in support scenarios.  But that's absolutely not a hard and fast rule!

[Mrinal Mondal]

Thanks Nic, for the nicely knitted answer.

I get the picture of these three frameworks. Now my question is if I migrate data from Jira to Jira Service Desk, will there be any way I can create a framework like Sprint/Kanban? Or do I have to adapt the Queue at the Jira Service Desk?

Also at Sprint and Kanban, I know what ticket (Issue or Task) is going to end. Does JSD have such options?

[Nic Brough -Adaptavist-]

Whilst I've talked about the principles in general (and not any deep detail), I should also say that Jira mostly asks you to pick the most appropriate and go with it.

If you migrate your issues from Jira or Jira Software to Service Desk, then you'll find JSD is built mainly on queues.  The queues are expected to be where your people draw work from, and what they will be measured on (via SLAs)

It would not make any sense to execute JSD queue based stuff in a Scrum way.  With support, your queues tell you what you need to look at next, and you are measured on how you deal with each item at the top of the queue.  In Scrum, the team decides what is most important, and are measured on what they deliver, not what's most important for a different group.  It's almost impossible to handle support in a scrum/sprint process sensibly, they're just two different things.

Kanban is a bit closer to support, because you can do "here's the queue, set the Kanban backlog/to-do-list to match", so that when an dev finishes a task, they can go to the next item in the queue automatically.

And, of course, you can hybridise all three approaches.  What you need to look at is what is going to work best for what you are trying to do, not any one standard way to do it for the sake of it.  What process are you trying to build and how are you measuring progress and success?