The behavior of the burndown chart has been altered in Sprint 0.7.2.0. This rectifies the problems of the original implementation.

If a task is removed or added to a Sprint, it changes the scope of the entire Sprint, not just the scope from the point in time that it is changed going forward. Therefore, the logic is that the "ceiling" of the Sprint, which represents the scope of total points, floats based on task removal, points addition or task addition. Points remaining is then simply a calculation of the difference between task points assigned to "Done" and the ceiling at that point in time.

For further details about this change, please see the Release Notes here: https://github.com/wikimedia/phabricator-extensions-Sprint/blob/master/RELEASE_NOTES.md

Thanks @christoper for the fix and explanation.

However, I'm afraid I disagree with this model. I'd prefer to be able to learn from our past sprints about how we over/underestimated and what actions (if any) we took to rectify it so that the burn down actually represents what happened in the sprint rather than an idealized version based on the final scope (otherwise we can always just remove what didn't get finished on the last day). We can make it work if this is the consensus, but wanted to put that out there.

I am not sure that I understand your concern. The way that the application works should not change the way that a Sprint is scoped. When a Sprint is completed, the tasks that are left unfinished should be left in the status columns where they were at that time. Then, it represents a snapshot of the time period. Subsequent Sprints can change the column status of those same tasks freely without affecting the previous Sprint status position.. This is actually another benefit of the new model that depends on the Board status only for the Burndown chart. If Maniphest status is used, then these snapshots would not be possible.

I'm happy to see how it plays out with what you push out in the new
release. Thanks for your work, @Christopher

I agree with atgo. Start points should stay fixed as a representation of what the team committed to at the sprint kickoff, and the remaining points line should move based on tasks added or removed.

The team committing to a certain scope of work/number of points (based on data about their past performance) at the outset of a sprint is an important principle. If a task is added midway through, something else should be removed. The way that this works on phab08 right now obscures the fact that the scope was changed (as far as I can tell from my experimentation).

My two cents, also want to say thanks for the great work Christopher :-)

Scope changes during a Sprint are a practical reality. The problem that you address here is however difficult to resolve functionally. The obfuscation of project scope reduction changes in the Sprint extension is a consequence of a Phabricator transaction limitation . The transaction that records the removal of a project from a task is recorded for the task, but not for the project. Thus, a task that is removed from a Sprint project is untraceable within that project, because it is no longer in the project scope. It is simply not possible to keep a record of removed tasks from a project at this point.

Scope additions are traceable, however. Events are created and this can be seen in the event log. The scope metrics that define what a Sprint represents should be applied consistently for the entire Sprint in order for "ideal points" and "remaining points" to have any meaning. Scope addition changes midway through the Sprint do in fact add points to the points remaining, but points remaining cannot be calculated based on an inconsistent ceiling.

The logic then follows that if points are changed for a task or a task is added to the Sprint during the Sprint, the changes are retroactive for the entire scope. The alternative of allowing a per diem Sprint scope is confusing, and really not that useful in my opinion. A Sprint is defined by an objective for a period of time. Allowing the objective to be dynamically defined during the period muddles the function of the objective, which is to complete the estimated scope.

Estimation is an inexact science, but an important part of project planning. The real value of Sprint planning is in allocating appropriate resources for the estimated tasks so that the objective is completed. Modifying the scope may solve the short term resource problem, but does not really help with ensuring that the estimated scope is used as metric for refining appropriate resource allocations for a project.

I am fine to try out what you've done, particularly understanding the limitations of function you mention.

In T89305#1038969, @Christopher wrote:

Estimation is an inexact science, but an important part of project planning. The real value of Sprint planning is in allocating appropriate resources for the estimated tasks so that the objective is completed. Modifying the scope may solve the short term resource problem, but does not really help with ensuring that the estimated scope is used as metric for refining appropriate resource allocations for a project.

I think @KLans_WMF and I agree on your point here that estimation is hugely important. But I definitely want to empower my team to recognize when planning was off in order to consciously drop some items rather than have hangover sprint to sprint. This isn't something that should happen all the time, but it's a healthy practice, IMO.