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
Status: | new → assigned |
---|
comment:2 Changed 16 years ago by
Summary: | Using dynamic dates instead of collecting historical data → Collecting data for milestones that were not yet started |
---|---|
Type: | defect → enhancement |
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.
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?