As a sprint team, we would like the option to measure work-in-progress (WIP) limits based on card count, to more closely adhere to Kanban standards.
On Wikimedia's Phabricator instance we have Points enabled. So, at the moment, a Task has 0 Points as default. At the moment, WIP limits are shown as a total of Story Points, but this is a misuse of story points.
This means that
- if a column is filled with un-pointed tasks, the WIP stays at 0. Bugs are commonly 0 points.
- WIP is not measured by the Kanban standard of task count. It is uncommon for Kanban to use WIP with points.
Acceptance Criteria:
- an option to change a board to show WIP by task count in a column, rather than point total (or, alternatively, replace the existing functionality with this one)
- preferably, the option is on the board itself, and not in editing the project
It's been suggested that simply defaulting all tasks to 1 point solves this issue. However, that raises other issues (for instance, some teams may already be using the Story Points field for actual story-pointing).
Original upstream ticket: https://secure.phabricator.com/T10915
Original Wikimedia ticket: https://phabricator.wikimedia.org/T120042
== Proposal n. 1 "Just adding Count limit" ==
Proposed changes - __only when Story Points are enabled__:
* [ ] Every Column has a new "Count Limit" (integer) - NULL as default
* [ ] If specified, and if exceeds, the Column turns red (just like it happens when it exceeded the indicated Points)
In short:
| When Story Points | Task Points | Column "Points Limit" |New Field "Count Limit"| Migrations |
|-------------------|----------------|------------------------|-----------------------|------------|
| **Disabled** | 🟢 Hidden | 🟢 Used as Count limit | ➕ (Hide Count Limit) | 🟢 none |
| **Enabled** | 🟢 Shown | 🟢 Used as Point limit | ➕ Show Count Limit | 🟢 none |
Legend:
* 🟢: just the current situation
* ➕: addition of something
Note that - when Story Points are disabled - we can keep everything as-is. Anyway, keeping everything as-is can be confusing, since at the moment the "Point Limit" is always shown, and in fact it is to be understood as "Count Limit" if Points are disabled. Anyway it seems everybody likes the current implementation, so let's just keep everything as-is for people with Points disabled, in this proposal. -- @valerio.bozzolan
Pros:
* on Points disabled: zero changes, total backward compatibility
* on Points enabled: absolute minimal additions, maximum backward compatibility
== Proposal n. 2 "Let's also refactor" ==
This proposal is a bit arrogant but in the end it is logical. It attempts to work the Unix way, in which one thing does one thing.
Proposed changes:
* [ ] __Whenever Points are enabled or not__: Columns: add a new "Count Limit" (integer) - NULL as default
* [ ] If specified, and if exceeds, the Column turns red (just like it happens when it exceeded the indicated Points)
* [ ] __Only if Points are disabled__, try do do not show "Point"-related stuff and do not use Point-related database fields
In short:
| When Story Points | Task Points| Column "Points Limit" | New Field "Count Limit" | Migrations |
|-------------------|------------|------------------------------|---------------------------|----------------------------------------|
| **Disabled** | 🟢 Hidden | 🟠 Hide this misleading field | ➕ Show Count Limit | 🟠 Migrate "Point Limit" as Count Limit |
| **Enabled** | 🟢 Shown | 🟢 Used as Point Limit | ➕ (Hide Count Limit) | 🟢 None |
Legend:
* 🟢: just the current situation
* 🟠: breaking change
* ➕: addition of something
Honestly if Phorge was my personal project I would proceed in this direction. But, if there is at least one stakeholder who would prefer to avoid this, let's avoid this. Having said that the only people with breaking changes are those with Point disabled && that are using APIs to count the "points" (that, for them, was the max count - so they probably knew it didn't make a lot of sense). -- @valerio.bozzolan