Implementing Kanban WIP Limits in Greenhopper

As per the booked called KANBAN - Successful Evolutionary Change for your Technology Business by David Anderson, the WIP limit shoould be set in such a way that you consider the In Progress and Done columns together towards the WIP limit. However, the Rapid Board does not allow this functionality. It only allows setting the limits on one column at a time.

Question - Is there a way to enforce (or even visually indicate) WIP violations when the WIP is to be managed as two columns together?

4 answers

I tackled this problem by having a single column with both "in development" and "ready to test" statuses, and then having a single WIP limit on the column. The workflow I had allowed the team to drag an issue into the column which would give it a "in development" status. To move to "ready for test" they simple had to "." to bring up the operations screen, and select the first item in the operations list, which was the next stage in the workflow, in this case "ready for test". I also coloured coded the issues using a query so that I could show the issue as blue when it was "in development" and green when it was marked as "ready for test".

This is a good workaround until the issue is resolved:

As I understand your question.... How do I add the "In Progress" and "Complete" states together for any Kanban/Mfg cell in my workflow.... e.g. If the Wip limit is 3, that includes in process as well as complete items not yet taken by a following process. ( or alternatively the inbound "Ready for" queue and "In Process" items )

My answer would be "Not in the same Rapid Board Configuration". So you could have multiple configurations and swiitch between them.

In the Rapid Board I would put both states into a single column so the limit is applying to the total work in progress and done. You've got your hard combined limit setup. Now using two swimlanes, one for the queue and the other for in process, you can eye the number of items in process (filter using assignee = empty, or user to determine the issue's swimlane). This works well if you have few in process items and there is a 1:1 relationship of "Technical Task" to "Assignee". A workflow post function to clear assignee when Done (or placed in the "Ready For" queue and it should be fairly clean. I realize this is not exactly what you were asking but would it work for you?

You could also have another Rapid View Configuration focused on assigned tasks looking at only the "In Process" statuses to check the corresponding swim lane above. Sort of a check totals, and then check in process two-step.

But the problem with using swim lanes, to differentiate between WIP and Done within a single limit, is that you cannot simply move issues from WIP to Done. You need ton explicitly change the status by opening up the issue.

Are there plans for Atlassian to develop a better solution with Greenhopper?

0 votes

Issue tracking a similar request:

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

626 views 0 7
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you