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.

@MBinder_WMF

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.

@MBinder_WMF

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

This would be useful!

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.

@Christopher

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?

Thanks!

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: https://secure.phabricator.com/T10915

@Aklapper

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. :)

@Aklapper
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 https://secure.phabricator.com/T10915 (as Andre said earlier in the comments).

@greg
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?

Hi, see https://www.mediawiki.org/wiki/Phabricator/Code

Added a ticket: https://we.phorge.it/T15100

:)

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)?