KANBAN: WIP Limits only for Tasks, Subtasks and Bugs

[Matthew King Lloyd the third of Bonn]

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 :/

[Matthew King Lloyd the third of Bonn]

Anyone?

[miikhy]

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

[Matthew King Lloyd the third of Bonn]

@miikhy 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]

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

[Matthew King Lloyd the third of Bonn]

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 @miikhy I am currently changing perspective.

[Jack Brickey]

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'.

[Matthew King Lloyd the third of Bonn]

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?

[Matthew King Lloyd the third of Bonn]

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 :)

[miikhy]

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 :)

[John Cooley]

This seems like an obvious miss on Atlassian's part.  Rather than debate theories of Agile and justifications for how it should be done to workaround this board visualization design flaw, please just add a checkbox list on issue types to include in the Column limit.  

[Jan Wedel]

Hi, just found this discussion here. We have a similar problem and I've created a feature request:

https://jira.atlassian.com/browse/JRASERVER-69546

If you still need this, please consider voting for it. If you've found a work-around, please share :)

[Bhabindra Bahadur]

As tracking we would want to see how epics/stories/tasks/sub tasks is picked up and what status it is in.

I use multiple boards for this 

1) Epic board/ Story Board (here i dont add constraints)

2) Tasks/sub tasks board. here i add the constraints, since we need to check as a team if we have picked too much and blocked.