Page MenuHomePhabricator

Non-numeric maniphest.points values
Closed, WontfixPublic



On our Phabricator installation we have different groups using Maniphest to schedule their work, with different expectations about the granularity of the "points" (time estimate) field of tasks. Even within one project the desired precision might vary between tasks: Sometimes a job roughly requires "N days", while other tasks can be estimated more precisely to a much shorter time, e.g. "M hours".

Maniphest currently allows to change the interpretation of the time estimate through the configuration value maniphest.points, which allows to change the field labels. On our instance we chose "days" as the granularity, but in more fine-granular tasks this results in estimates like "0.125 days" when we actually mean "1 hour" (8h per working day). Additionally, with people on the team, who work only a certain (small) number of hours per week, this results in meaningless estimates (they don't work 5 days per week, thus the term "day" is meaningless to them). On the other hand, an estimate of "32 hours" for a task would suggest a fine precision that is not actually intended, if we actually mean "roughly 4 days".


To accommodate this kind of variance within one installation and to add flexibility, I propose to allow non-numeric values for the Maniphest points field, to support values like 3d or 3d 5h or 5h. Counts of the same type (i.e. "d/days" or "h/hours") could be summed up on the Projects Workboard. The implementation would not even have to know about the concept of "days" and "hours" to carry out this aggregation.

Automatically aggregating "hours" into "days" could have undesired effects, as different installations (or groups on one installation) might have different assumptions how many hours make up one working day (e.g. one group/instance might have 8h working days, while all of the people in another group work only half-time and thus have 4h working days, etc.). Thus my proposal to only aggregate numbers of the same type (i.e. suffix), without applying a specific interpretation.

Event Timeline

epriestley claimed this task.
epriestley added a subscriber: epriestley.

I do not plan to pursue any variation on points which can not be summed in a linear way. You can find some discussion under "Quantitative" in T4427#157820.

If points aren't numeric and summable, a lot of current and planned features won't work. These features currently exist, and would not work, or would require substantial revision:

  • Column limits.
  • Project status bars.

These features are planned or speculated, and could not be built, or would require substantial additional complexity:

  • Querying points by tasks (T10339).
  • General reporting systems, burndown charts, etc (T4171 / T1562).
  • Possible revisions to project overviews (explorations in M10).

If you just want a qualitative label to appear on workboards, you might be able to use project tags (for "Small", "Medium", "Large") or T4863 may provide a mechanism. But I don't expect us to ever build support for multi-dimensional points which are summable per-dimension but not comparable across dimensions, since there's basically nothing we can do with them.

In many project management schemes, points are explicitly not a direct scheduling mechanism. The use of "points" -- not "hours" -- is to make the values comparable across tasks, regardless of who completes them. A new employee and an experienced employee may take a very different number of hours to complete the same task, but they can usually both agree that the task is worth "1 point" or "5 points" under some definition of complexity. The "points" mechanism in Phabricator is intended to serve Agile / Scrum / Kanban styles where the value is intentionally a function of the task only, not the task and the assignee.

We may build more explicit scheduling features into Phabricator eventually, but don't currently have any plans to pursue this. In particular, I suspect the only multi-dimensional values any install would ever want to use here are time (hours / days) and maybe materials (physical hard costs), and both of these would be better handled through more sophisticated systems that were aware of time and currency units.