Don't link the start of burndown Guideline and start of the sprint

[scott.fawcett]

It's so much easier to go through sprint planning after the sprint has started.  One example is that we can't accurately plan a sprint when we don't know the amount of carry-over, which happens automatically when you start the sprint.  And it's much easier to use the plug-in Capacity Tracker when it's showing the current sprint (which it won't do by default until the sprint has been Started).

But, once you start a sprint it sets the line for the Guideline on the burndown chart...which means you need to have the work (tasks) completed otherwise you get a worthless burndown chart.

I need a way to start the sprint, but don't yet set the markers for the sprint burndown chart.  When sprint planning is complete, and I'm confident the team has been properly loaded, I then want to "start" the sprint burndown chart so that the Guideline is correct.

[Earl McCutcheon]

Hi Scott,

The Burndown charts are for showing the estimated work committed to the sprint at time of start compared to the actual work completed during the sprint.  This will follow a cycle of "Plan > Start > Work > Stop > Review", and in the sprint process it is expected and designed around the expectation that once a sprint is started any items modified or added after start is considered scope creep, so this is not a possibility by the design of the application around the sprint planning process.

Pulling a quote from the Article "Inside Atlassian: 4 ways to deal with scope creep" :

Scope creep is when a project grows beyond its original ambition while in progress (i.e., work added that was not part of an original sprint, epic, or even release).

If you're looking for an option to build out a better roadmap across multiple sprints for future planning efforts I would recommend looking into a either Portfolio For jira which is a roadmapping tool made by atlassian or an alternative such as BigPicture - Project Management & PPM as a third party option for a tool to help plan out the sprints more accurately with better future projections.  A good comparison between these tools can be seen here

Regards,
Earl