Kanban WIP Limits

[samba]

I'm considering using GitHub's Projects feature for a new startup, small team, rapidly iterating software product.

I'd like to use a Kanban workflow. One of the most important rules of Kanban is limiting work-in-progress.

When I create a GitHub Project in my organization, it appears I cannot apply a WIP limit to any column. It appears column capacity limits are not supported at all. Is this true? Am I missing something?

Are there any plans to support configurable WIP limits or column maximum capacity in a Project?

Thank you!

[belauzas]

I would argue and I would support you, but WIP limit makes sense only if it's actually about how many issues a single person can have with a WIP status, like 1 or 2 at a time.

On the other hand, there is some issues with that...
Lets say:

• I have a limit of 2 WIP's/person;
• I have completed both of them;
• each issue has it's own PR card on Kanban board;
• what should I do? I take another issue...
• both of my PR's are rejected;
• now I have 3 WIP's... now, that's a problem, because I had a limit of 2 WIP's... 😬

[samba]

When I implement kanban with a team, I set the limit based on the characteristics of the team, including its size. In some teams 2 per person is the upper limit; in others, where an item cannot be completed without multiple people of various skills (eg front- and backend together), the limit may be 1/2 relative to team size. Sometimes we find reasons to adjust the limit over time.

The problem with your exceptional case is that the critical path (and value stream) exceeds the scope of your team. Kanban may not the best choice for you, or perhaps kanban should be applied in conjunction with better communication and leadership, to facilitate collaboration across multiple teams. No kanban board can solve that.

That’s also not a reason to exclude the WIP limit feature from a tool purported to support kanban, in my view. I’d rather let my organizational problems be made visible ;)

[samba]

Nonetheless, I emphatically assert that your first point is absolutely correct.

A person can actually do only one thing at a time, especially in software where problems and objectives are often complex, arising from the behaviors of multiple components.

Creating focus for individuals, and for entire teams, is a vital quality enabler, and by extension accelerates throughput (“speed”) of delivery, by reducing rework.

[erinmez]

I would love to see WIP Limits implemented. I would even go one step further and request that one can split a column into an "On-Going" & "Done" column. Whether those are visually contained in one column or normal columns is not that important, but rather that I can configure them to share/count towards a same WIP limit (limits are the numbers in red in the image).

[aguywithcode]

WiP limits aren't for individuals. I think there's a fundamental misunderstanding there. The WiP limit is for the step in the value stream (the column on a Kanban board). Kanban is a pull system, if there is congestion at one column, that is a SIGNAL. You should look to address that congestion.

Addressing your issue, WiP is not an individual metric. If your developer has completed a story and the Development column is at its WiP limit, that means people should be pulling stories into PR review (which is part of your value chain). If the PR review column is also at its WiP limit, that means people should focus on completing reviews.

[mfiumara]

Would love this +1

[tylfin]

One really good way to do this is just have the column highlighted red when the limit is exceeded vs. making it impossible to transition the state

[curtisbarnard]

I agree. I think ClickUp has a feature that works this way.

[nbarbettini]

This (without any additional constraints) would be a great addition!

[curtisbarnard]

I also would love to see this feature! I think it's a feature that is lacking on a lot of boards that are claiming to be kanban and a potential market differentiator for GitHub Issues.

[dashdeckers]

I agree this would be a great feature. I would love to be able to make use of more advanced Kanban features for projects (lead time, metrics, WIP on swimlanes, etc)

[freepour]

I believe supporting this feature would allow startups to lean more heavily on GitHub for planning and management instead of trying to connect other tools to it

[mawkee]

I'm also really interested in this

[bennettale]

+1

[redcatbear]

WiP limits are essential for Kanban, so this would be a big step forward.

And (I hope the GitHub developers don't mind my unqualified assumption here 😃) it sounds like a quick win with comparably moderate effort, as long as you start with one limit per column.

[redcatbear]

Until the feature is available on GitHub, we created a browser plugin that others might find useful too.

While the plugin is currently only tested with Firefox, we plan to test on other browsers to. You can find the XPI package on https://addons.mozilla.org/en-US/firefox/addon/github-project-tweaks/

Project homepage is https://github.com/exasol/github-project-tweaks-browser-extension, feedback and contributions welcome. It's Open Source.

See also: exasol/github-project-tweaks-browser-extension#1

[rileybroughten]

👋 Hello! Some questions and notes here to check in as this discussion was started a couple years back:

• Since this discussion was created, we've added the support to display sums for numerical fields on columns, as well as adding descriptions for single-select fields & board columns where you can highlight details of a column, such as a "definition" for a status. Does this help accomplish how you set and highlight limits for your teams on the board?
• When thinking about limits, do you think about them as a numeric field (such as Estimate), number of items, something else more custom?
• What would you want to see once a "limit" is reached? Is it visually highlighting to show that there are more items than there should be in a given column? Prompting you in some way?

[danm]

thanks @rileybroughten

Since this discussion was created, we've added the support to display sums for numerical fields on columns, as well as adding descriptions for single-select fields & board columns where you can highlight details of a column, such as a "definition" for a status. Does this help accomplish how you set and highlight limits for your teams on the board?

No, I think something visual to show a limit is about to be breached (amber) and breached (red). Much like redcatbear's extension. Additionally, the option of preventing moving a ticket into a state where the WIP limit has been breached. Though, this is probably doable with Github actions.

When thinking about limits, do you think about them as a numeric field (such as Estimate), number of items, something else more custom?

This limit is a number that corresponds with the number of issues in that column, so yeah, a numeric field.

What would you want to see once a "limit" is reached? Is it visually highlighting to show that there are more items than there should be in a given column? Prompting you in some way?

An example of what this feature could look like... if the WIP limit is 6, there are 5 issues in "In Progress", and the column becomes amber. Once that 6th issue enters the column it turns red. I believe this is how JIRA works.

[mawkee]

Hello @rileybroughten
My 2 cents on this:

1. I don't think it does. It helps add a sum for something on each card, but not a count of cards (that's already present)
2. WIP would be the number of cards on a column or a group of columns
3. A visual indicator that the column is over the limit would be useful, as well as a warning prompt letting you know that moving the card would put the column above the WIP limit (but not prevent it altogether)

[nbarbettini]

@rileybroughten To add on to what @mawkee said, in my mind the smallest MVP of WIP limits is:

1. A configurable numeric limit to the number of items in a column. Different columns can have different limits.
2. A visual indicator on the entire column when it is over the limit.

For example, if I set the limit on my column "In progress" to 3, and drag a 4th item into that column, I would see a visual indication that the column is over the limit.

[redcatbear]

I agree with that MVP.

What is the purpose of the WiP limit?

1. You want your team to immediately realize when they bite off more than they can chew at the same time.
2. You want to be able to argue with your PO / PM or supervisor that your team needs to focus on getting started things finished before starting something new in parallel that will then take longer.

Both goals can be achieved with something as simple as a big red frame around the column that is over the WiP limit. No need to go fancier than that.

It's all about: stop starting, start finishing.

[rileybroughten]

This is coming! 🎉 See github/roadmap#788 👀

[rileybroughten]

This has shipped! 🚀 Check out the changelog announcement and let us know what you think!

[erinmez]

Apologies for being late to the party, but this is implemented in a suboptimal way. If we are talking about Kanban, an On-Going and Done column for each area/step is needed to signal and buffer work correctly (e.g. Agile Project Management with Kanban used in some Teams in Microsoft). In this scenario, it does not make sense to have WIP-Limits on either one or the other or both columns. It simply does not work:

• if the WIP limit is only on the on-going column:
  people can fill up the done column & there is no incentive to empty the done column by moving items to the next step's on-going column

• if the WIP limit is only on the done column:
  people can start new work items as they please with no boundary and once they are finished they are breaching the WIP limit of done.
  Thus the signaling is wrong, they should not have started the work in the first place.

• if the WIP limit is on both columns:
  people are constraint in starting new work, which is good. However, the signaling is still wrong, namely they should not start work when the done column has reached the WIP limit.

[mawkee]

As I understand, this is a MVP for WiP limits, and not the "best optimal solution that will work for every case". While I agree that this could be improved in many ways (not only from the one you pointed out), it doesn't mean that this is not useful as-is. I'd argue this covers most of the cases.

Multi-column limits would solve your case (as well as one of my cases), but it's probably much more finicky to get done right. But I'd say we need to evaluate this solution as previously proposed and implemented before suggesting next steps.

[estoner]

I'm delighted that y'all did this! Thanks!

[mawkee]

Hey @rileybroughten ! I've tested it, and it works really well, specially for a first mvp/iteration of the feature. Does what it's supposed to, the warning is discrete but effective, and it blends in really well! That's awesome

[erinmez]

Hi all, I think it is necessary to revisit this topic (wip limits across multiple columns) . Please see here and vote if you have a similar need:
https://github.com/orgs/community/discussions/103010

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐