The upcoming Sprint extension upgrade changes the way that a Sprint project is defined. The special character requirement in the name has been removed in favor of a checkbox ("Is Sprint") found on the Project Profile.
After the upgrade, previously defined Sprint projects will have to be reinitialized with the checkbox and the start and end dates will have to be reentered. All tasks and task points for these projects will remain unaffected.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Aklapper | T89646 Notify existing Sprint Projects about new Sprint extension upgrade changes | |||
| Resolved | • chasemp | T86772 Next Phabricator upgrade on 2015-02-18 | |||
| Invalid | • chasemp | T89824 post T86772 |
To confirm - the upgrade is supposed to be tomorrow? Will there be a comment here about when it's happened so that we can reenter the dates?
Phabricator update has happened.
The following projects need to set their sprint dates again by editing their project:
In addition, #§Collaboration-Team needs to also enable the "Is sprint" checkbox as I do not have permissions to edit that project.
Also added that comment to T86772 and sending an email to teampractices@.
For future reference we need to become better in communication. :-/
All Sprints have been reinitialized with the previously defined start and end dates.
The following Projects were not assigned start and end dates yet. When initializing a Sprint project, please always define start and end dates.
#§_fundraising_sprint_e
#§_fundraising_tech_backlog
#§collaboration-team
Fundraising Dash (obsolete)
These two projects are marked as sprints so that the team can estimate tasks before they end up in an active sprint. If you have a better workaround, I'm eager to hear it, but these won't have start/end dates.
#§_fundraising_tech_backlog
Fundraising Dash (obsolete)
Even so, a Sprint project is still defined by a period. If you are not using it for Sprint progress tracking, then just assign it a long duration. 01-01-2015 to 12-01-2015.
Yes @Awjrichards, that's the current state. @Christopher I still don't see the reason for the long duration - the date fields are optional in the UI. Are they not actually optional?
Also since this update none of my burndown charts are displaying anything. Should I open another bug?
@atgo The implementation of the burndown chart is no longer connected with Maniphest status, but the column position of the task in the board. To see progress on the burndown, the final column name should be renamed "Done". Anything that was moved to this column will then show as a deduction from points remaining at the time that it was moved. The Sprint extension naming conventions for the column types are currently defined as "Backlog", "Doing", "Review" and "Done". This does not mean that you need to use these column names, but if you want to see charts, then this is the currently defined standard.
While the date fields appear to be optional, if a project is initialized as a Sprint and does not have these dates, it will throw an implementation incomplete exception when attempting to access the burndown chart and the Sprint list. I consider these fields to be required, and perhaps an interface should be developed that does not allow Sprint initialization without them.
@Awjrichards Regarding the ability to record task points without a Sprint project, this would require the field to appear globally for all projects. And, I do not think that this is going to happen. So, the fact is that points can only be assigned to tasks that are in a Sprint project. I recommend that you just consider the duration to be arbitrary for the Backlog projects, but it still should be identified.
Thanks, fixed that.
While the date fields appear to be optional, if a project is initialized as a Sprint and does not have these dates, it will throw an implementation incomplete exception when attempting to access the burndown chart and the Sprint list. I consider these fields to be required, and perhaps an interface should be developed that does not allow Sprint initialization without them.
This isn't the nicest experience for users, but I get the limitations. I'll update mine today.
@Awjrichards Regarding the ability to record task points without a Sprint project, this would require the field to appear globally for all projects. And, I do not think that this is going to happen. So, the fact is that points can only be assigned to tasks that are in a Sprint project. I recommend that you just consider the duration to be arbitrary for the Backlog projects, but it still should be identified.
It would be so cool if it would appear :)
All sprints are now required to have explicit start and end dates. Thus, what is the benefit of a Done column? To determine what was done in a sprint, I can easily query what is Resolved and within that sprint. I recommend the burndown chart do the same. This list of Resolved tasks should never become unwieldy, as long as you make a new sprint project (with new dates) for each actual sprint.
The only way you can avoid making a new sprint is to change the dates when a new sprint starts. However, I think that is a much less optimal solution, both because it makes Resolved less useful (requiring some kind of Archived column to avoid an endless less of Done/Resolved) and because the dates should be an inherent property of the sprint.
The meaning of "Done" is clearly different than "Resolved". "Done" is defined differently for each Team, "Resolved" is not. "Resolved" means that the task should be removed from the current activity list for all projects, and is basically closed. "Done", on the other hand, is contextual to a specific project. For example, there could be two teams, one that handles code and the other deployment, with separate boards. When the code team finishes their work on a task, it is moved to "Done", but should not be considered "Resolved" until all associated projects have moved it to their "Done".
The importance of "Done" to the Sprint project is that it defines "completion of the Sprint objective" in terms of the capabilities of the team, but not necessarily ultimate task resolution. A Sprint is defined by an objective for a specific time period. It should only include the tasks that are estimated to be completed within that time period.
It seems that the problem you have is not with the reasoning behind the "Done" column, but with the overall scope and definition of the Sprint, which may be too large to be managed. I think that most Teams would be happy to see an overflowing list of Done tasks.
@Christopher @Mattflaschen there is one big challenge I see with using the 'Done' column as the signifier for the burndown chart. For teams who work iteratively on say, two week iterations, a burndown chart is not terribly useful at the sprint level. For delivering on your sprint commitments, who really cares if the charts burns down steadily over the two weeks, or all at once at the end. Burndown charts are much more useful over longer time horizons - say planning for a release, or for a quarter, or whatever (more than one sprint-length) - so that you can more accurately predict when you might be 'done' with a release, or use it as an artifact to help justify scope reduction, etc. In order to get that kind of view now, you'd have to create one sprint project that spans the release timeline (say, one quarter), and then one project per sprint. To get the release burndown to be accurate, you would have to move tasks to the 'Done' column not just in the sprint view, but also in the release view.
For example, there could be two teams, one that handles code and the other deployment, with separate boards. When the code team finishes their work on a task, it is moved to "Done", but should not be considered "Resolved" until all associated projects have moved it to their "Done".
If two teams disagree about whether a task is Resolved, that may be an indication that a subtask should have been used instead. I don't know of any pair of teams that tracks deployment of tasks in this manner.
It seems that the problem you have is not with the reasoning behind the "Done" column, but with the overall scope and definition of the Sprint, which may be too large to be managed. I think that most Teams would be happy to see an overflowing list of Done tasks.
My point about sprint scope was simple: If a new project is created for every sprint, clutter will never accumulate.
A long list of tasks accomplished in the current sprint period is great. I think a long list of tasks from prior sprints tends to clutter the board.
Our team does in fact create a new board for every two-week sprint currently.
I agree with @Awjrichards that a Done column can create redundancy (when the task is Resolved, every team that cares about it has to drag it to Done).
The problem of redundancy that occurs between tracking and release projects can be solved when/if upstream implements "sub-projects" (see T78259). Until the logic that connects different projects and their tasks is better developed, the desired behaviour that provides linking between board columns from multiple projects is outside of the scope of the Sprint extension.
Regarding whether there exist multiple teams for task resolution and deployment, the Sprint extension is the perfect example. If I finish the code for a bug and merge it into the production branch of Sprint, as far as I am concerned it is "Done". However, the task is not officially "Resolved" until the code is deployed into production and verified by the users. This can occur, in some cases, weeks or even months after the code changes have been merged. Since, deployment is handled by another, entirely independent team, the final resolution of the task would be in their project purview, not mine.
Out of curiosity, are these differing definitions of 'done' documented somewhere? IMO this sounds like a great candidate for two separate tasks; I don't see the value of calling a task 'done' in one place but not in another.
A couple of notes about the latest Sprint changes.
Enjoy.