CC'ing @Christopher as he maintains the Phabricator-Sprint-Extension so he's the obvious contact to potentially discuss burndown chart functionality scope.

Here is a brief commentary. I am in the process of reworking the Sprint extension to not depend on Maniphest task status. The trend in Phabricator is to make task management focused on the Workboard. I agree with this. The current logic that connects the Burndown Chart to Maniphest transactions is really cumbersome, and it breaks under certain conditions (e.g when multiple projects are assigned to the same task).

The new approach will derive the chart only from the positions of the tasks on the Workboard. This frees project managers from having to define progress on the burndown chart as a consequence of the limitations of the default Maniphest task status.. For example, whether or not a task is considered resolved only when it is deployed and verified (the Bugzilla status that Phabricator does not have). For many Scrum masters, a task is done when it has been merged. Additionally, since there is no Patch to Review task status in Maniphest, it is undefined how review patches should be reflected in the current Burndown chart.

Since the workboard column names can be customized, it may be worthwhile to define constants that connect the Sprint extension Burndown Chart to them. Wikidata favors "Doing", "Review" and "Done". Progress on the burndown chart will then follow the assignments of tasks to these columns and not on the Maniphest task status designation. Also, it is then possible to have backlog tasks in a Sprint, but not reflected on the Burndown chart. Only tasks in "Doing" would add to the total points for that Sprint. A prototype for review should be ready by the end of next week.

Regarding the feasibility of maintaining the Sprint extension in phabricator.wikimedia.org generally, this is another question. I am not convinced that the added value of this extension is worth the continued maintenance that it will require going forward as Phabricator upstream evolves. However, if continuous integration is used, then breaking changes should be easy to flag, and the decision to disable or deprecate the Sprint extension can be made at that time.

I appreciate the approach of having the burndown generated based on the workboard instead of task status. However, I've a comment on one of the details.

In T88328#1017426, @Christopher wrote:

Since the workboard column names can be customized, it may be worthwhile to define constants that connect the Sprint extension Burndown Chart to them. Wikidata favors "Doing", "Review" and "Done". Progress on the burndown chart will then follow the assignments of tasks to these columns and not on the Maniphest task status designation. Also, it is then possible to have backlog tasks in a Sprint, but not reflected on the Burndown chart. Only tasks in "Doing" would add to the total points for that Sprint. A prototype for review should be ready by the end of next week.

I would prefer to also add the Sprint Backlog column to the total points. Only considering "Doing" would be cumbersome as the content of this column changes constantly during a sprint. Only if a developer is actually working actively on a task it is moved to "Doing". Since a developer generally works on several tasks one after the other during a sprint, he would constantly picking up new tasks from the sprint backlog and moving them to "Doing". Also since tasks in the "review" column are still considered "not done", they should also add to the total number of tasks.
In short, I suggest having "Sprint Backlog", "Doing" and "Review" adding to the total number of open tasks of a sprint and "Done" adding to the number of closed tasks.

Hi @Christopher, thanks for the note.

In T88328#1017426, @Christopher wrote:

The current logic that connects the Burndown Chart to Maniphest transactions is really cumbersome, and it breaks under certain conditions (e.g when multiple projects are assigned to the same task).

Ouch! A few questions - would you mind elaborating on what 'it breaks' means? How does that manifest? Are there plans to address the issue you described? What are the other known issues? Are the issues being tracked somewhere?

The new approach will derive the chart only from the positions of the tasks on the Workboard. This frees project managers from having to define progress on the burndown chart as a consequence of the limitations of the default Maniphest task status.. For example, whether or not a task is considered resolved only when it is deployed and verified (the Bugzilla status that Phabricator does not have). For many Scrum masters, a task is done when it has been merged. Additionally, since there is no Patch to Review task status in Maniphest, it is undefined how review patches should be reflected in the current Burndown chart.

Since the workboard column names can be customized, it may be worthwhile to define constants that connect the Sprint extension Burndown Chart to them. Wikidata favors "Doing", "Review" and "Done". Progress on the burndown chart will then follow the assignments of tasks to these columns and not on the Maniphest task status designation. Also, it is then possible to have backlog tasks in a Sprint, but not reflected on the Burndown chart. Only tasks in "Doing" would add to the total points for that Sprint. A prototype for review should be ready by the end of next week.

I see your point about wanting to tie burndown progress to a specific column (columns?) of the work-board - it sounds like this would resolve an issue around different interpretations of what 'resolved' actually means. The desire to standardize and workboard columns seems like a logical step, however I am concerned this would erode much of the power of workboards. Regardless of whether or not a team is using Scrum by the book, the workboard should reflect the real workflow of a team, with columns representing the different hand-off points in the system (eg 'ready for development' to 'in development', or your example of 'doing' to 'review') - these are going to vary by team.

I would argue in favor of keeping the burndown progress tied to a task's actual state (eg resolved) and enforce social conventions around who can resolve a task, and leave the definition of what 'resolved' means up to the team in question. If a team feels 'resolved' means code is merged and deployed, then I don't see why it would be a problem to indicate this on the burndown chart.

Regarding the feasibility of maintaining the Sprint extension in phabricator.wikimedia.org generally, this is another question. I am not convinced that the added value of this extension is worth the continued maintenance that it will require going forward as Phabricator upstream evolves. However, if continuous integration is used, then breaking changes should be easy to flag, and the decision to disable or deprecate the Sprint extension can be made at that time.

Just to make sure I understand you correctly, are you saying that you are not planning/willing to continue maintain the sprint extension in Phabricator?

FYI: Sprint Extension 0.7.0.1 is ready for review here: https://phab08.wmflabs.org/project/sprint/burn/6/

This includes a lot of changes and bug fixes. I want to get feedback and then get it deployed (see T85123), because I think that it has improved to a large extent.

Regarding the labeling of columns as a reflection of "the power the workboard", the intent of this switch from Maniphest is not to restrict custom labeling, but rather to define a manageable status typology that works for the Sprint workflow. For most cases, 4 primary types (Backlog, Doing, Review and Done) seem adequate enough. The mapping of unique names to the typology can be done by adding new label constants as needed. The default Maniphest Task Statuses do not work for Sprints, this much should be clear. Also, the dynamics of the sprint process do not have to be constrained by the formality of changing a task status, which seems to be a more "official" process and may be considered more definitive or final.

One last point is that a Sprint is a Project. Managing task status is a project responsibility and ultimately depends on team constraints. I would argue that task status also has a function of notifying associated projects of overall task progress. And, this underlines the problem that was originally defined here as having multiple projects associated with a task. What happens when two teams are working on the same task? How is team progress able to be measured when there is only one "task status" field?

I hope that the logic of this method change is clear and that people will be able to use the charts for some reporting and overall team benefit.

In T88328#1024741, @Christopher wrote:

FYI: Sprint Extension 0.7.0.1 is ready for review here: https://phab08.wmflabs.org/project/sprint/burn/6/

Looking pretty damn good. Nice.

@KLans_WMF is going to take the new sprint extension for a test drive with the mobile apps team and experiment with the new burndown functionality for the duration of one of their sprints and report back on the experience.

@KLans_WMF, @ggellerman head's up that the updated sprint extension has been deployed to production phabricator

In T88328#1018432, @Awjrichards wrote:

Regarding the feasibility of maintaining the Sprint extension in phabricator.wikimedia.org generally, this is another question. I am not convinced that the added value of this extension is worth the continued maintenance that it will require going forward as Phabricator upstream evolves. However, if continuous integration is used, then breaking changes should be easy to flag, and the decision to disable or deprecate the Sprint extension can be made at that time.

Just to make sure I understand you correctly, are you saying that you are not planning/willing to continue maintain the sprint extension in Phabricator?

@Christopher I'm still curious - are you planning to continue maintain the sprint extension? Are you open/willing/able to make feature changes and enhancements?

FYI, I'm going to try out burndown charts with these app team sprints (Phab board links below, this is also a trial of Phab for sprint planning/working for the team). These sprints kick off on Feb 30.

https://phabricator.wikimedia.org/project/view/1065/
https://phabricator.wikimedia.org/project/view/1066/

Changing scope a bit; going to set up burndown chart for App projects.