Page MenuHomePhorge

[Feature request] Option to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards.
Open, Needs TriagePublic

Description

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 PointsTask PointsColumn "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 PointsTask PointsColumn "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

Event Timeline

I wonder if this could be just a patch that assumes Story Points = 1 as sane default instead of zero.

Uhm. It seems that Phorge/Phabricator does - as default - this thing that 1 point = 1 card.

For a proof of that, just visit this page in this very same website I'm writing where "custom Story Points" are not enabled:

https://we.phorge.it/tag/phorge_upstream/ - see that there are 7 points and 7 cards.

Note that this "custom story points" thing is probably enabled only in Wikimedia Phabricator, not in Phabricator/Phorge itself.

I don't know how to rephrase the title of this Task with this info.

valerio.bozzolan renamed this task from [Feature request] Option to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards. to [Feature request] Maniphest Points: default to 1, not 0 (to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards).Mar 13 2023, 07:15
valerio.bozzolan updated the task description. (Show Details)

@MBinder_WMF Does it still describes your goals, or have I distorted it too much?

By the way I have not understood if you are aware of this situation (I was not):

https://secure.phabricator.com/T10915#188323

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

I saw this sentence and I didn't understand it. I don't see how varying the default "assumed value" could create problems. If you have a suspicion please clarify that it would help me a lot to understand. I definitely have a limited view on the impact of this. I think someone might complain if they set the Tasks Points as 0.1 or 0.5 or other fractions and then Β«oh no, the default is worth moreΒ». But honestly it seems to me that more people are complaining about defaulting to zero, than people are complaining about a future natural defaulting to 1 (which the user can still change per-Task, by the way).

Hi! Thanks for following up on this. :)

As I mentioned in my original description, defaulting to "1" solves one problem and creates another. I don't think it is a legitimate solution. "1" means something already, and as you suggested fractional pointing is also a thing. Bugs also do not get points.

Uhm. It seems that Phorge/Phabricator does - as default - this thing that 1 point = 1 card.

I'm not sure this is true. I think it's just the card count, and the Story Points are not active.

By the way I have not understood if you are aware of this situation (I was not):

https://secure.phabricator.com/T10915#188323

I have seen this, thanks for raising it again. In my opinion and experience, users don't understand this, so while the data "should already be pretty reasonably available" in the UI, it is not in the UX. This strikes me as a "see documentation" approach to "won't fix" rather than bringing the software up to standards. It's asking too much of the user, especially if they expect something else.

MBinder_WMF renamed this task from [Feature request] Maniphest Points: default to 1, not 0 (to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards) to [Feature request] Option to measure WIP limits based on card count instead of points, to more closely adhere to Kanban standards..Mar 16 2023, 18:26

So, if I have understood correctly,

You say: it would be nice to have: 1 - not just this:

Phorge Points.png (117Γ—620 px, 7 KB)

But - in addition to Point Limit - also another field like Count Limit - and somehow highlight not just when you go over the first limit, but also when you go over the second. Is it right?

(Note that I'm just a Phorge user and not a maintainer or site admin - I'm just trying to help for no good reason in the world. I know Phorge can be frustrating but let's improve this nice piece of software ihih)

Thanks for your help! Much appreciated that the attention on this is being raised. :)

Really, there is no such thing as "point limit" in standard practice, at least for columns (there are limits for entire sprints, but that's another thing). The fix should really be changing WIP to use count, not points. I just didn't want to advocate for removing something that someone might be using by now, so I've focused on what my users want.

However, if it is easier to shift rather than add the feature, that is preferable!

I don't think the hundreds of installations that use Phorge would want to abandon the way they do their thing so drastically. That is why I suggest to think about something that helps both them and you.

For example, if you ignore the columns for a moment and don't use them, what you say then would make sense for the Milestones as-is. So, you create a Milestone (note: a Milestone can have columns), and you set Point Limit to that Milestone. Then, you say: I would like, on the Milestone's columns, to have a limit per count of Task and not another limit by Point. This is probably reasonable enough.

Tell me if we can formalize it better not to be too drastic.

Knowing Phabricator community a little, I don't think this feature was implemented so lightly and so wrong as you mention. I want to say, I think therefore people will be not willing to accept "their" workflows as wrong and "your" as correct, and we should avoid a breaking change. We probably can.

I like your assumption of good faith! I'm a little more cynical about the thoughtfulness of Phab development, and the thoroughness of features deployed. I'll try to follow your example. :)

In any case, I don't think we need to advocate to remove story point WIP (I was just explaining my ideal). I think we need to advocate to add and option for task count WIP, and to stop using the existence of story point WIP as an excuse to not, especially considering Kanban, where WIP tends to originate, traditionally does not use story points.

I honestly think that adding a new feature called "Count Limit" on Columns would be useful for you, so that you can use Points Limit on Milestones; and Count Limit on Columns (and ignore Point Limit on Columns).

Feel free to mention a reading or training to further deepen this specific workflow, so maybe other volunteers/folks can better understand this point of view.

Having said that, in the meanwhile, as workaround, probably you could just - in few clicks - add "1" as Point in each Task. Then, use the Point Limit just as a "Count Limit" logically. If you would go for this approach, it would be great for you, because then you could ask the Wikimedia Foundation to, simply, assume 1 Task = 1 point by default, and I think that would not be a problem for anyone there. I say this since I want to suggest something quickly feasible for you, without waiting to reach consensus for a breaking change on everyone else in the Phorge world (which in any case maybe deserves a discussion).

Thanks for the suggestion. Default-to-1 has been mentioned before, and it's not feasible because of teams that need to cross-tag, where some teams use Story Points and some don't (thus, 1 point means something to one team but another thing to another). It's also common for 2 teams to use story points but have different meanings, where 1 point is a totally different scale depending on context.

I agree, adding count limit to columns and retaining point limit for milestones is an ideal compromise. :)

It's not that anyone is complaining about WIP'ing story points (it's just odd because it's not really a thing), it's that WIP, in Agile development, is designed for Kanban and task count, and it can't be used in its current iteration (so nobody in our org does, despite the feature trying to exist).

I've shared two proposals, that are actually requests for comments. I would be glad if some people could give a look and share a comment.

@MBinder_WMF: Also, under the hood you're saying that, since Wikimedia have multiple teams (multiple Tags) it would be nice to allow to change Task Points without interfering each other,

So, it would be be nice to save Points also on the tuple <Task, Tag>, so each team can override Task Points without interfering with others' logic.

β†’ This thing is safe to be discussed separately from this Task since it has no influence on the two approaches exposed here.

@MBinder_WMF - how much of this will be solved if we just add a tooltip to the [ X | Y / Z ] header?

In T15100#5480, @avivey wrote:

@MBinder_WMF - how much of this will be solved if we just add a tooltip to the [ X | Y / Z ] header?

By "tooltip" do you mean something that activates when hovering with a mouse?

By "tooltip" do you mean something that activates when hovering with a mouse?

Yes - some text describing what the code means.

I think a tooltip would clear up some of the confusion around the numbers and what they mean. However, I think the issue described here is less about how confusing it is, and more about how the UX expectation is typically centered around count rather than points. For example, which has the denominator, turns the UI red, etc. So, a good idea! I just think it's separate. :)

OK.

I don't personally have much insight into the "board" functionality, because I've never used boards in any setup other then as a simple table, and none of the workflows that involve moving small pieces of paper around make sense to me.

But this task, along with T15131, T15210, and all most of https://secure.phabricator.com/project/view/773/ do suggest some technical changes into making more-abstract "columns of things" setup, with the goal of allowing (probably using extension code) to define custom "board" setups.

there is a presentation from eric brechner, who was in microsofts xbox development, about kanban. he does it on whiteboard, extremely sinple:
https://www.youtube.com/watch?v=CD0y-aU1sXo

if phorge could do something like this would be extremely cool.

I'm not skilled enough to look into the bigger picture, however maybe the Edit Column dialog could have a third field apart from Name and Point Limit to also have Task Limit (or Card Limit?). Point Limit and Task Limit then must be mutually exclusive (do not allow to set both for a column, or even...board?), somehow.

Workboard column header could display either 47 | 12 / 30 for Point Limit approach, or 47 / 100 | 12 for Task Limit approach.

FYI the pointLimit is stored as a JSON blob in the database:

MariaDB [phabricator_project]> SELECT * FROM project_column WHERE projectPHID = "PHID-PROJ-4kojgq6jwufprm4pt43t";
+----+--------------------------------+------+--------+----------+--------------------------------+-------------+--------------+-----------------------------------+--------------------------------+-------------+
| id | phid                           | name | status | sequence | projectPHID                    | dateCreated | dateModified | properties                        | proxyPHID                      | triggerPHID |
+----+--------------------------------+------+--------+----------+--------------------------------+-------------+--------------+-----------------------------------+--------------------------------+-------------+
| 32 | PHID-PCOL-7mid4xx7pyqjzyujx3z2 |      |      0 |        0 | PHID-PROJ-4kojgq6jwufprm4pt43t |  1721727719 |   1722552452 | {"isDefault":true,"pointLimit":3} | NULL                           | NULL        |
| 33 | PHID-PCOL-zbk3hpjltigossjmowvn |      |      0 |        1 | PHID-PROJ-4kojgq6jwufprm4pt43t |  1722528500 |   1722528500 | []                                | PHID-PROJ-nlxnc4jw2ek6nx2wvwdk | NULL        |
+----+--------------------------------+------+--------+----------+--------------------------------+-------------+--------------+-----------------------------------+--------------------------------+-------------+
2 rows in set (0.001 sec)