Modify

Opened 16 years ago

Last modified 16 years ago

#4413 assigned enhancement

Collecting data for milestones that were not yet started

Reported by: Filipe Correia Owned by: daan
Priority: normal Component: ScrumBurndownPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description

With the implementation of ticket #1462 we can now set a new start date for a give milestone, which is great, but I'm now not sure how should the chart behave when this feature is used...

I tried defining a start date for a milestone that has started a few weeks ago, and was expecting to see a chart for this entire period when selecting the right milestone on the burndown tab. However, what happens is that the chart for this milestone keeps being displayed as it was started today, even though it does contain some previously closed tickets.

I think I understand why this happens (please confirm): the chart data is actually stored as we go adding time and closing tickets, so even if we change the start date, the 'historical' data as registered by the ScrumBurndownPlugin won't be affected, and the plotted chart will be the same.

In spite of this, I still wish I could see the burndown for milestones that have started before the plugin was in use, and even for milestones that have already been closed, as it may allow to better understand the project's work-cycle, and better plan for the future.

My suggestion (not sure if this is even doable) is that the chart is plotted on the fly, from the TimingAndEstimationPlugin data (estimated hours and total hours) and from the ticket data (which milestone does it belong to, when was it added and when was it closed), instead of keeping historical data specific for ScrumBurndownPlugin.

Something that may become an issue with this approach is that tickets that are removed or added after the milestone's start date won't be reflected on the burndown chart (btw, this was also an issue discussed in ticket #1292). However, maybe it's not that bad to allow modifying a chart on a past time-frame; after all, if we think of a milestone as a sprint, adding and removing tickets should be avoided as much as possible, so, when it does happen, it is probably to correct some misuse of trac, and make it reflect what really happened.

Attachments (0)

Change History (2)

comment:1 Changed 16 years ago by daan

Status: newassigned

I think fetching the historical data from the ticket data will get pretty slow....

What I can change easily, is that 'not yet started' milestones also collect data. Would that be a solution?

  • Daan

comment:2 Changed 16 years ago by Filipe Correia

Summary: Using dynamic dates instead of collecting historical dataCollecting data for milestones that were not yet started
Type: defectenhancement

Hmmm, I guess it would. Sounds good!

And furthermore, when the plugin is first installed, historical data could be collected for all already existing ticket data or, alternatively, just give an admin option to collect it on user demand.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as assigned The owner will remain daan.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.