It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

KANBAN: WIP Limits only for Tasks, Subtasks and Bugs

Matthias Wehnert May 08, 2018

Hey there,

we moved our physical Kanban board to Jira Online because our team works from different locations and apart from that there are definitely other benefits of Jira.

 

Our workflow looks (a little bit simplified) like that: We have two Kanban boards.

  • Backlog Kanban: It's like a discovery Kanban board, where we sort out requests we won't do and define the other requests until we have all the information we need to start the developements process. Most of the time the requests are Stories; while defining we often create Sub-Tasks. The Sub-Tasks are between 2h and 8h (sometimes 16h). It's a very basic board with only 3 columns without WIP Limits etc etc. You might say we are only using it to qualify the requests and produce a valid backlog.
  • Task Kanban: That's our delivery Kanban system. We work on the Stories, but in fact we are pulling the Sub-Tasks through the Kanban workflow. And adjust the corresponding Stories when all subtasks have moved.

But now I encounter a problem: 

We have added WIP Limits to the Task Kanban board. Since the actual packages of word the developers are working on are the Sub-Tasks (and maybe Bugs and sometimes stand-alone Tasks) we included these in the counting of WIP. But now if a Story has 3 Sub-Tasks, there 4 counts on the WIP. 1 for the Story and 3 for the Sub-Tasks. 

I tried to exclude Stories and Epics from the board. Now the Stories are not counting in the WIP Limits but they are also missing when I want to use the Kanban-Backlog. :/

 

Are there any best practices for situations like this?

What do you think?

Might we just limit Storie in Progress (SIP = WIP)? But my concern is, that our Stories are so big :/

5 comments

Matthias Wehnert May 09, 2018

Anyone?

Micky CARITTE Community Leader May 09, 2018

Hi Matthias,

Welcome on Community first!

As per your situation, I can't see any "ideal" solution. Subtasks are not standalone on boards, you got this, and I can imagine increasing the WIP Limit might not help in case you have many subtasks under a single story.

An alternative could be to use Epics are you current stories and Stories as your current subtasks but it's clearly not ideal again: you loose the Epic level, and you reuse items with the wrong naming and eventually setup.

Another alternative could be to link your tasks with Stories (not using subtasks). It's not as good as subtasks graphically but the linked issues panel is still there, you can add a new link type eventually. If you combine that with Exocet addon for instance, you can even build a new panel with linked issues and some of their fields. If you're tracking time and want to aggregate it, that might be different...

Your final point is quite good as well: in Agile theory, a Story is short enough to fit in a Sprint (I know it's theory). If you can manage to shape your stories differently (to avoid subtasks) that could be a nice way to do so, but can require a bit of change management.

A last alternative is to use  Portoflio for Jira Parent Link on Tasks instead of using subtasks. This is a bit of an overkill in my opinion but....

Hope you'll find the best way to manage that! Let us know!

Cheers

Matthias Wehnert May 09, 2018 • edited

@Micky CARITTE Thank you for your answer :)

As for the suggestion of using Epics as Stories and so on: I think it would only move the problem, because I would want to have Epics (former Stories) and Stories (former Sub-Tasks) on 1 board, but only count the Stories into the WIP Limits while being able to have both in the Kanban Backlog.

Same with the Task-linking idea. ;)

What I have learned: I might need to change perspective! 

Scott Theus Community Leader May 09, 2018

Hi Matthias,

I have a project that sounds like it has a similar scale as yours. In my project the subtasks were large (over 8 hours) and I wanted to limit them to be work that could be completed in a single day. (Assuming full resources, no conflicts, etc. etc. etc.)

Similar to Micky, I set my Epics as Projects in JIra, my Stories as Epics, and my Subtasks as Stories. By product backlog (your backlog Kanban) includes the stories while during Sprint Planning the Scrum team breaks down the stories in to subtasks and moves those into the sprint backlog (your task backlog.)

We use Big Picture here to manage the multiple projects at a program level rather than Portfolio.

-Scott

Matthias Wehnert May 09, 2018 • edited

The thing is: Our team in a whole is not doing Scrum. We have a daily qualified backlog of Epics, Stories, Tasks, Bugs and Sub-Tasks. And we want to prioritize these, but not on a Sub-Task level. On the other hand, our idea was to limit the Sub-Tasks, because this is what the devs are doing.

I was hoping being able to set up a integrated solution of both, but as I answered @Micky CARITTE I am currently changing perspective.

Jack Brickey Community Leader May 09, 2018

Just an opinion so feel free to cast it aside. I'm not a huge fan of using WIP limits. I have used in very rare occasions but generally I find it best to have the teams learn their abilities and manage their WIP. Certainly column constraints can be useful to illustrate 'too much' or 'too little'.

Matthias Wehnert May 09, 2018 • edited

We are - as a team - managing our WIP, by giving us WIP Limits. This helps us to prioritize work, as we only have a certain capacity and say "No" to stakeholders :)

The thing is, that we work on multiple projects and of course every project manager (customer) thinks he is the most important one. So we tend to commit to more tasks than we are able to handle. You see?

Matthias Wehnert May 09, 2018 • edited

The perspective changing led me to the following idea: 

Maybe we real thing, we should limit are Stories (and Tasks, Bugs etc.), not the Sub-Tasks. Because, what brings the value to the customer is not a new column in the database or a button without underlying function!

By limiting the Stories we would be able to force our workflow to produce value by completing Stories.

We could still use Sub-Tasks to structure the work, that needs to be done on the Story (Task, Bug, ...) and we could use the Kanban-Backlog to prioritize :) What do you think? 

PS: Thanks to everyone participating on this :)

Micky CARITTE Community Leader May 09, 2018

Definitely a great approach: Stories bringing real values are what matters to stakeholders. By excluding the subtasks from the board, you won't loose their usage (for technical actions) but will track a higher level of things. You might want to complete it with a few gadgets on devs dashboards to get them a view of their subtasks with different filters :)

Comment

Log in or Sign up to comment
Community showcase
Published in Jira

Try Jira Cloud for Outlook: Organize your work without leaving your inbox

Hi Atlassian community, My name is Max and I work on the product integration team at Atlassian. I am pleased to announce the early access program for the Jira Cloud add-in for Outlook. This add-in...

2,172 views 6 15
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you