Modify ↓
Opened 18 years ago
Closed 18 years ago
#638 closed enhancement (invalid)
Add validation to ScrumBurndownPlugin for closing tickets
Reported by: | Sam Bloomquist | Owned by: | Sam Bloomquist |
---|---|---|---|
Priority: | low | Component: | ScrumBurndownPlugin |
Severity: | minor | Keywords: | |
Cc: | Trac Release: | 0.10 |
Description
You should not be able to close a ticket unless the time_spent and current_estimate are equal to each other.
Attachments (1)
Change History (5)
comment:1 Changed 18 years ago by
Changed 18 years ago by
Attachment: | automaticclose-diff.patch added |
---|
patch that automatically sets the estimated time to 0 when a ticket is closed
comment:2 Changed 18 years ago by
Trac Release: | 0.9 → 0.10 |
---|
One additional small comment: your wiki states that you need a integer data type (to be added to the trac somehow). I could not figure out how to do that (trac 0.10) but it seems to work with custom ticket fields based on text.
Keeping the fields text makes it much more simple to install and use the plugin.
comment:3 Changed 18 years ago by
Priority: | normal → low |
---|
comment:4 Changed 18 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
I'm closing this one because the burndown_job.py already ignores closed tickets so this isn't really necessary.
Note: See
TracTickets for help on using
tickets.
As mentioned in ticket:637 I have a patch available that will automatically put the current_estimate to 0 when the ticket is closed.
It is used like that because we do the planning according the daily scrum, see http://www.mountaingoatsoftware.com/scrum/dailymeeting.php and update the time we expect to work on the ticket, not the amount of time we did work on the ticket. That way, the current estimate should move towards 0 when you are done with the ticket (original estimate and time spent are not used in this scenario).
As we use the SVN hooks to automatically close tickets, it means that no additional work on the website is required for the developer in order to deal with the burndown (in the perfect world ;) )
Do you mind to keep this scenario in mind too when you create this enhancement ? Patch file is attached to give you an idea how it was solved (pretty simple)