Page MenuHomePhabricator

Create/enable custom "Story Points" field for tasks
Closed, DeclinedPublic

Description

fab.wmflabs.org had field for agile points that was removed at T64#39 in order to offer the simplest UI for new/casual users -- and also because the current need for it wasn't very clear. Some teams seem to want them back.

When @Qgil was playing with permissions, he wasn't able to make this field visible only to members of the Triagers group, just like the rest of fields for power users. We need to investigate whether this is a limitation of Phabricator and, if so, report it upstream.

Details

Reference
fl646

Event Timeline

flimport raised the priority of this task from to Normal.Sep 12 2014, 1:49 AM
flimport set Reference to fl646.

qgil wrote on 2014-09-07 08:35:39 (UTC)

To me this task has two blockers:

  1. Labs content migrated to Wikimedia Phabricator instance in production. It is about to happen and we don't want to introduce any changes here now. I don't need to ask @Rush to know that this requirement needs no discussion. :)
  2. "Agile Points" field not visible for plain Phabricator users. Offering the simplest UI to all users by default is a heavier factor. Do you agree?

I would add that some documentation about what these points are and how are we using them would be useful. I recall several users not knowing what to do with them (including myself on my first day using Phabricator).

aklapper wrote on 2014-09-07 12:34:08 (UTC)

Some teams seem to want them back.

Who? We do not offer a custom field for agile points as long as there are no tools to display points (T244). If some teams have some tools to query that custom field in Phabricator, I'd like to be aware of these tools. Or do people copy points of closed tasks into some Google Docs table for their team?

Rush wrote on 2014-09-07 13:09:24 (UTC)

I think maybe at some point it will make sense to have a "type" of task (bug, ops issue, non-technical) idk. There are more advanced custom field options available than how points were done, but I generally agree on the UI stuff. It will get messy quick without being very judicious about ticket fields. Either way, seems like an ongoing discussion.

greg wrote on 2014-09-07 15:44:34 (UTC)

(I edited the title/description based on my understanding that this isn't custom to us since I see it available on upstream Phabricator'x Phab.)

Story points (search for "story points" for a wealth of info on how they're used) are fundamental to how Agile teams work. Without at least the ability to hack something out of Phab (ie: have the story points in the Phab Task edit, like it is upstream, and allow a script to query that for reporting.)

Also, story points are a very important use case was for the burn-down/up charts that are in-progress (right?). Just having a burn-down/up of # of tasks isn't sufficient for Agile (trademark or no) team.

I'd prefer them to be available to those in the Triagers group. I want to be able to create a ticket with story points from the beginning (not having to click edit after creation) and I want my team to be able to edit the story points with as little friction as possible.

qgil wrote on 2014-09-07 15:48:36 (UTC)

greg wrote on 2014-09-07 16:07:11 (UTC)

(I might have been wrong about where the 'customization' lives, feel free to re-title/describe more accurately.)

Looking at the volunteer contributed burn-down chart readme "Story Points" is a required custom field for it to work:
https://github.com/bluehawk/phabricator-sprint

Thus, I think we should have it :)

tobijat wrote on 2014-09-08 12:21:16 (UTC)

I think not having the functionality implemented e.g. in https://github.com/bluehawk/phabricator-sprint in Phabricator would be a blocker for our team (Wikidata) to migrate to Phabricator.

aklapper wrote on 2014-09-08 16:21:05 (UTC)

and allow a script to query that for reporting.

@greg: Is writing such a script on the to-do list of anybody, or would people rather wait for a proper solution in T244 to actually use those Story Points in tasks? I'm still wondering how these points would actually be used, gathered, analyzed without having burndown charts at the beginning.
(Trying to understand what each team is up to, and at least Analytics, Wikidata and Greg's team have interest in burndown and points.)

To quote the Wikidata team, "If it is easy to enable these fields when we want to deploy the phabricator-sprint tool (T244), we do not make this a blocker for the initial migration" so I'm removing the bugzilla-migration project again on this task.

Adding that custom field is rather easy (though we'd like to potentially hide it for average users not intended to set or use it).

Maybe we can have story points editable only by some, in the form of an advanced custom field.

Should the group of people be the Triagers or a specific group e.g. Scrummasters?

Gilles added a subscriber: Gilles.EditedOct 9 2014, 7:44 AM

I don't particularly have a preference as to which group should have that right, as long as all the members of my team get it, since any of us update points on Mingle in our current workflow.

@Aklapper Workboards currently mention "points". Which I believe just mean the amount of tasks at the moment (i.e. one task = one point). Already displaying story points on the workboards would be very useful, and replicate the core existing use case for story points on Mingle.

Gilles added a comment.Oct 9 2014, 7:45 AM
This comment was removed by Gilles.
Qgil moved this task from Backlog to Doing on the Project-Management board.Oct 22 2014, 11:13 PM

not all teams that use story points necessarily care about burndown charts.

Turns out that at least Mobile and Multimedia are not using burndown charts (T153), but they rely on T803: Show task Story Points sums in workboards.

After this explanation of the Sprint extension, it is unclear to me whether the story points are brought by the extension, or whether they need to be enabled to Maniphest separately. Also, whether teams willing points will also use the extension or not, or whether it can be both, or whether the question doesn't matter...

Sorry for the vague questions (that maybe have been answered as well). This reminds me... we will need some basic documentation. a section in https://www.mediawiki.org/wiki/Phabricator/Project_management ?

Sprint is entirely optional for all teams. The only thing that triggers a project as a Sprint is the use of the special character (§) in the project title.

The custom field implementations use the Standard Phabricator Custom Field interface which allows proxying. Proxies allow a field to use some other field's implementation for most of its behavior while still subclassing the application field. For example, the Sprint Project Start Date Field proxies the Standard Custom Field Date, which is used in many other applications. Nothing needs to be enabled in the applications that Sprint depends on (Projects and Maniphest) for this to occur. The benefit of this is that it is impossible for Sprint to break any other uses of the field, because its behavior is subclassed within the application.

The Sprint application context is routed with URLs, like all Phabricator applications. So, any requests passed to /sprint will be handled by the Sprint controller.

In other words, projects interested in story points should use Sprint, even if they would ignore the burndown chart generated?

Maybe someone interested in points-not-charts wants to try this in http://phab08.wmflabs.org and see whether this is a good solution. The advantage is that we would save a "Points" form field to all the rest of projects/users relying on plain Maniphest.

Tnegrin set Security to None.Dec 1 2014, 6:58 PM
Tnegrin added a subscriber: Tnegrin.
Qgil closed this task as Declined.EditedDec 2 2014, 8:38 AM
Qgil claimed this task.
In T452#786265, @Qgil wrote:

In other words, projects interested in story points should use Sprint, even if they would ignore the burndown chart generated?

Assuming Yes for now and resolving Declined for a custom field that would be visible in all tasks.

The Sprint extension will land soon here (T1322). Teams interested in story points are encouraged to try it out and see whether this solution works for them. If there is something to be polished, first they should try to improve Sprint itself. There are two main benefits to this approach:

  1. We need to maintain just one type of story points and not two (the ones available through the Sprint extension).
  2. Story points will appear only in Sprint projects, meaning that regular users not following sprints won't need to see them in the task creation/edition form and most of the tasks they visit.