<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve > When facilitating planning at scale across many teams or groups within my organization, I want a high level view of how my epics are moving through a workflow, so that I can track and report on the progress of features and initiatives. How might we allow users to limit the amount of work items in one list in order to optimize their Kanban throughput? ### User experience goal Users can limit epics being worked on within any one workflow, which actually speeds up the process and encourages collaboration. ### Proposal | List settings drawer | WIP limit set in a list | | ------ | ------ | ||| **Figma:** https://www.figma.com/file/epYXyMqBv0LdJ5F2coAMTf/and-2864-Program-boards?node-id=128%3A20273 - Clicking on the `List settings` button within a list opens up the `List settings` drawer, consistent with the current experience in issue boards. - Users can set a work in progress limit by number of epics. This is indicated both in the `List settings` drawer and in the list itself in the count. The count should read `current number of epics / wip limit number of epics` - If a work in progress limit is exceeded, the list will turn red and the current number of epics within the count will turn red as well to indicate the offending count. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? Users are setting work in progress limits in order to optimize throughput. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->