Uuuuggggh. Hold on, are you asking to have task count be "story points" on some projects, but "story points" be "story points" on others?

If it's just a global setting baked into 'story points', it seems reasonable, but I recall we (or maybe just @epriestley) thought this was a bad idea™

You can set a global default in Edit Task → Configure Form → Edit Form Configuration → Change Default Values → Type Some Number → Save Defaults.

Evan's brain is more brain than my brain today.

Some teams are confident that they can evenly size tasks

(Also, do you know if this is this empirically true, for "normal" software engineering sorts of tasks? I believe this is remarkable achievement if it is.)

...and the simple task count ones were just as good

Oh, I read to the end of the sentence.

At least the default seems better, since they can change it in cases where it's not correct.

You can set a global default in...

oh, I was looking in /config → maniphest.points → trying to add something like "default"

In T10915#173710, @chad wrote:

Uuuuggggh. Hold on, are you asking to have task count be "story points" on some projects, but "story points" be "story points" on others?

Well, Right Now I would be happy with "tasks as points" globally. But I'd be a little worried if that meant I had to tell a team they could never use "points as points" later. Setting the default in all forms will probably spark a philosophical argument over what "normal" is but sounds reasonable.

(Also, do you know if this is this empirically true, for "normal" software engineering sorts of tasks? I believe this is remarkable achievement if it is.)

You read to the end of the sentence faster than I could generate a new one.

There has been some discussion about this request in T120042. It would be very useful to some teams that I work with as an Agile Coach for them to have the ability to limit work in process in columns by number of tasks rather than points. That is their workflow which Phab used to support, and the change has led to some confusion about how much work is in process.

So if there is a way to prioritize this feature request, we would be grateful. Thanks!

In T10915#173714, @epriestley wrote:

You can set a global default in Edit Task → Configure Form → Edit Form Configuration → Change Default Values → Type Some Number → Save Defaults.

@chad Thanks! And thanks to @epriestley, too. When I tried that, I got error "You do not have permission to configure forms for this application"

You should talk to whoever administrates your install. They may have it locked.

The specific request of the WMF teams is for the workboard column WIP limit to be measured in task count rather than story points. We have been directed to this task for that request, although it's not clear to me that they are actually the same thing. We really don't want to treat tasks as if they had a story point value of 1.

For our case, defaulting every story's points to 1 might be an adequate workaround, but it's not really what WMF teams have asked for want:

• Teams might want to estimate some stories, but might also want the per-column WIP limits to be applied based on task counts rather than story points.
• Also, jamming an estimate of 1 into every task would make it painful to switch later if a team decided they did want to start doing real estimations.

Just to clarify, workboard columns with a limit should currently show text like this in the header:

[ X | Y / Z ]

...where X is the task count, Y is the point count, and Z is the point limit. Here's an example:

This is showing 2 tasks, totaling 0 points of a limit of 3 points (neither of the tasks have any points in this case).

So my expectation is that all the information you need to follow "limit is in tasks, not points" should already be pretty reasonably available -- just look at X and Z instead of Y and Z. The counter won't turn red if you go over the limit, but you can see at a glance how many tasks are in the column and what limit has been set.

This use case seems rare: no other installs have expressed interest in it that I can recall, except in the variant sense in this task (1 task = 1 point); and it sounds like it is not used universally at WMF either. This use case also seems reasonably possible already, by using convention and looking at the numbers. Obviously, it would be nice for this use case if we had a flag so the "0" didn't show up and the element turned red when it went over the limit, but these seem like pretty minor inconveniences rather than dealbreakers for this workflow? Am I misunderstanding an aspect of this workflow or request?

@epriestley, I'd like to add a bit of extra support for this request. We used to use the column limit to see when we had too many tasks in a certain column. Since the switch to the point limit, we haven't been able to do that.

I work at WMF, on the Analytics team. You're right that this is not universally used at WMF, but it probably should be since it's an effective way to quickly see process bottlenecks. For example:

In Code Review column red: probably not enough time spent reviewing
In Progress column red: probably too much context switching

These conclusions are harder to draw with point limits, because big tasks need to get worked, and sometimes they just cause a column to go red because the whole team can't share one task.

If you pointed us to the code that works on this, we could submit a patch maybe?

Just to be completely sure I understand this:

Since the switch to the point limit, we haven't been able to do that.

You can do this by noticing that X is greater than Z, right? You'd just prefer that the UI turn red too? Or am I still misunderstanding, and there's some actual information missing beyond the red color?

Implementing this is not technically difficult, I am just very hesitant to implement upstream features which benefit a tiny number of users. Some discussion in T8227. I would not accept a patch to make this change; the issue is the lifetime cost of maintaining a feature which is potentially used by only some users on one install forever, not writing the initial patch.

I have no idea what percentage of phabricator current or future users will be task-count-centric rather than story-point-centric. Speaking generally, the Kanban ideal would use task counts, not points. (As compared to the Scrum and XP ideals, which would use points.)

My point is that measuring by task count is neither pervasive nor super-obscure. It is a standard accepted practice in some methodologies. Not supporting it (well) could dissuade some people from choosing phabricator.

I'm not in a position to say whether the impact would meet your threshold for adding and maintaining the feature. Just that it certainly isn't WMF-specific.

In T10915#188338, @epriestley wrote:

Just to be completely sure I understand this:

Since the switch to the point limit, we haven't been able to do that.

You can do this by noticing that X is greater than Z, right? You'd just prefer that the UI turn red too? Or am I still misunderstanding, and there's some actual information missing beyond the red color?

Not quite. We did setup our board [1] to have Z represent the task limit. But, since our tasks are pointed, and each task is at least 1 point, the limit is always going to be passed. So Y is always going to be greater than Z, even though X is not greater than Z. That means the display is always red. It would be ok if it was the other way around, but that wouldn't make sense.

Implementing this is not technically difficult, I am just very hesitant to implement upstream features which benefit a tiny number of users. Some discussion in T8227. I would not accept a patch to make this change; the issue is the lifetime cost of maintaining a feature which is potentially used by only some users on one install forever, not writing the initial patch.

That makes sense. But I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

Thanks for the consideration either way.

But I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

The "strong form" of WIP limit is presumably the column changing color, because this is something that will interrupt you and force you to notice the WIP limit even if you weren't thinking about it. The "weak form" of WIP limit, showing the numbers at the top, doesn't serve the interruptive function well, because unless you are looking for it, you won't see it. And because (X | Y / Z) demands extra effort to remember which is which, what they mean, and what the units are.

Therefore, a number-based strong WIP limit seems more useful to more people than point-based. The main use for point-based WIP limit in Scrum is during Team Planning, but that number usually changes sprint to sprint, and since that number is a focus of Team Planning the weak form of WIP limit is adequate there. So the best possible use of the strong WIP limit would depend on how many Kanban teams out there do point-based WIP instead of count-based, and the Kanban people seem to think count is the majority.

I agree with Kevin that the point limit seems a lot less useful than the task limit. They're both useful for different reasons, but having been a scrum master and on agile teams for the past 10 years, I find the task limit more fundamental to the processes I've seen.

The "strong form" of WIP limit is presumably the column changing color, because this is something that will interrupt you and force you to notice the WIP limit even if you weren't thinking about it. The "weak form" of WIP limit, showing the numbers at the top, doesn't serve the interruptive function well, because unless you are looking for it, you won't see it. And because (X | Y / Z) demands extra effort to remember which is which, what they mean, and what the units are.

Therefore, a number-based strong WIP limit seems more useful to more people than point-based.

Speaking generally, the Kanban ideal would use task counts, not points. (As compared to the Scrum and XP ideals, which would use points.)

My point is that measuring by task count is neither pervasive nor super-obscure. It is a standard accepted practice in some methodologies.

I have little to add, but wanted to throw in my +1 to the above. :)

It may seem like a small impact, but it can have a big affect on teams that rely on traditional WIP. Thanks for your attention.

Thanks, @ksmith @milimetric @jaufrecht @mbinder! +1 to all of you

The Kanban workflow emphasizes limiting WIP which it does by setting task count limits. These limits inform not only that state (=column) of work but also when work can be pulled into the next state as capacity becomes available there. The idea is to reduce variability in flow through the system as well as align WIP with capacity.

In any event, thanks for your consideration.

Bumping this just to say that another team I work with wants to track WIP using count instead of points. In their case, they are a support team, so their board is populated by cross-tagging tasks that belong to other teams. When those cross-tag tasks have story points for the team that originated the task, the story points show on the support team, as well. This means that the support team can't default the story points to 1 just to get the count in WIP.

Anyway, not much more to add to the other existing comments, just wanted to provide another use-case. :)

Bumping again simply because this has come up a few times this month. Teams I work with want to use a WIP feature, but don't use the current implementation because it tracks points instead of tasks. Reviewing the rest of the comments in this thread, all of it remains relevant to those use-cases.

I think that this is something we(Wikimedia) can patch downstream in our fork, I don't think there is anything further to add to this upstream discussion.