Page MenuHomePhabricator

Option to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards.
Open, LowPublic


As a WMF sprint team, we would like the option to measure WIP limits based on card count, to more closely adhere to Kanban standards.

At the moment, WIP limits are shown as a total 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
  • preferably, the option is on the board itself, and not in editing the project

Upstream ticket:

Event Timeline

MBinder_WMF raised the priority of this task from to Needs Triage.
MBinder_WMF updated the task description. (Show Details)

if the maniphest.points global field is enabled, the default column point count is sourced only from points, not from tasks. The sprint extension is not managing workboards after the 18.02.2016 update, so this feature should be requested upstream.


Thank you for raising this issue. Re-enabling the Work in Process limits to be based on number of tasks would help Analytics Engineering and Research and Data teams as well as the Team Practices Group who have relied on that functionality.

Aklapper renamed this task from As a WMF sprint team, we would like the option to measure WIP limits based on card count, to more closely adhere to Kanban standards. to Option to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards..Mar 11 2016, 1:13 PM
Aklapper triaged this task as Low priority.
Aklapper updated the task description. (Show Details)


adding Design Research to the list of teams who would like the UI to count number of tasks in columns rather than the sum of points in the column

What is the use of points then if you base your limits on number of tasks?

@mmodell Story points allow a team to measure the uncertainty or complexity of a task. This is useful for a team that would like to measure its "velocity" (the average number of points completed per iteration) over time, and assist the predictability of delivery. Some tasks, such as bugs or research "spikes," are not assigned points. This is all common in Scrum.

Background aside, it is unusual for a team to limit work-in-progress (WIP) using points. For example, a WIP of "10" could support ten 1-point tasks, or two 5-point tasks, but those two scenarios are completely different in terms of work.

Additionally, some teams (especially in an environment with such a diverse spread of processes, like WMF) do not story points at all. A team using a traditional Kanban process, instead of Scrum, for example. The new Phab version made WIP limits impossible for anyone not using points.

one could also simply set a point value to 1 for tasks in the project and get the same result as a "points count disable, task count on" feature.


Thank you for input, but that sounds like a workaround and an extra step to replace a workflow that had been automatic for my teams.

@Christopher yes, thanks for suggesting that.

We had considered assigning a single point to all tasks to "fix" this, but as @ggellerman pointed out, it's enough overhead to be a lossy process. Additionally, some teams may still want to point tasks even though they use count-based WIP limiters, which would make this workaround very damaging to their velocity measurement.

The old Phab used the sprint extension, which behaved the same way as the new Phab points system (points WIP), but could be worked around via URL manipulation and bookmarking (to get count WIP). This is reflected in the description above. It was a really clunky way to address the need, and the new Phab version is much better in many regards, but this is a key feature that has now broken for many teams using count-based WIP.

@JAufrecht @ksmith @KLans_WMF @Awjrichards

Could you all please comment on how valuable restoring this functionality would be to you and your teams?


This would be helpful for the Discovery search and portal teams, and probably for Discovery-analysis and maps.

The lack of functionality for column count has broken a very common use case for several teams I work with: see how many tasks are in a column to gauge progress in working through the column, e.g., in triage.

Does card count (task count) imply that tasks are evenly sized?
If yes, there is now an upstream task that might welcome convincing use cases:


Thanks for response!

For Analytics Engineering team, the tasks are of varying sizes .

Having column WIP limits based on task count rather than points is useful regardless of whether tasks are evenly-sized.

The upstream task seems to be talking about progress bars, in which case evenness would be more relevant.

Just wanted to reiterate that teams are asking for this, lest it be forgotten. :)

I see that this task is marked low prio and is unassigned. Today it came to my attention that teams accustomed to limiting number of tasks in flight rather than number of points are still challenged to know how much work they have in process.

Would it be possible to raise the priority of this request? Thanks!

It's not something we (WMF) will do ourselves directly, most likely. The projects associated with this task hopefully indicate that it is an upstream Phabricator issue. So changing the priority here doesn't amount to much :).

The upstream task is probably (as Andre said earlier in the comments).

Thanks for pointing me to the correct task in which to leave comments. If WMF will not do the work requested in this task, is there any benefit to keeping it open? Thanks!

We keep track of them here so people don't continually report duplicates and as a way to determine what is actually needed from upstream. The projects (Phabricator (Upstream) and Upstream) should be enough for people to know it is a task for the upstream to deal with.

@mmodell This is something that has come up again a few times this month. I assume the situation is unchanged, but I just wanted to check with you if it's something we can now change ourselves, given your recent request on list to "please keep the feature requests coming." :-D

@MBinder_WMF This fell off my radar so thanks for bringing it up. As Evan points out in the upstream task, we could set the default value for story points to 1. That only solves half of the issue but then at least teams who aren't using story points at all could have the benefit without having to set each task to 1 point.

I could also run a bulk job to set the points to 1 on pre-existing tasks with no points assigned.

Does that seem worthwhile? I don't have a sense of which teams are using story points. I've only rarely seen the field used, honestly.

Thanks for picking this up again, @mmodell !

Setting default points seems like a bad idea to me. It's common enough that tasks don't get points for one reason or another (a spike task, a regression, forgetfulness) and teams use that as a signal for a conversation (e.g. "this task made it to code review without points so we should talk about the risk that introduced"). It also is complicated by tasks that are crosstagged, where one team is using points and another is not (or using a different scale).

My hope is that it's easier to direct the "x/y/z" instead. Evan suggested doing this manually, which in theory is sound but in reality the cowpaths that users take are incongruous with the approach. That is, people can do this, but it's annoying so they don't and instead ignore the process. How difficult is it to edit the WIP feature code to display count in the "/" section and points on their own (the opposite of what is happening now)? Genuinely asking, not snarking. :)

Adding @LGoto as an interested party.

@Aklapper What is the procedure for upstreaming these days, with Phacility shut down?

In the meantime, I wonder how hard it would be to replace our Phab instance functionality with this one. Standard caveats apply, of course (it's probably not as easy as I think, and there might be more than the zero people I see using the existing functionality). Having said that, my ignorant observation is that we could swap which number in the column is targeted (from points to count). I imagine a small UI tweak would be needed, too, so that the visual is on the right numbers.

Am I too optimistic (and or shouting into the void)?