search

backlogs / redmine_backlogs

A Redmine plugin for agile teams
https://backlogs.github.io/www/
GNU General Public License v2.0
773 stars 460 forks source link

The estimated time of issues changes to '0' #249

Closed sety closed 13 years ago

sety commented 13 years ago

After I have installed redmine backlogs 0.6.11, all estimated time of resolved issues change to '0'. The problem also occurs when I drag a issue to resolved column in task board.

retorquere commented 13 years ago

I take it "resolved" is a closed state. Backlog does that by design. The "estimated hours" field is treated as "remaining hours", you can see the initial estimate in the "initial estimate" field.

sety commented 13 years ago

If you modify the "estimated time", the "intitial estimate" won't change. So the "initial estimate" can't be treated as the real estimated time. I think the "remaining hours" can be simply computed by that "estimated time" subtract "spent time". Such the "estimated time" won't be set to zero. This is my opinion.

retorquere commented 13 years ago

I don't agree with that at all. That only works if you never make mistakes in your initial estimates, and your time tracking is perfect. I've seen neither in practice. Tracking spent time and time-remaining are both valuable precisely because you want to see the difference between these two.

sety commented 13 years ago

I agree that tracking spent time and remaining time are both valuable. I mean that storing remaining time in estimated time field is not a good idea. This may make somebody confused. And I find that when I log time, the remaining time won't reduce until I mark it as "Resolved", it reduce to zero suddenly.

bohansen commented 13 years ago

The way we use it is that everybody logs spent time and each day we update the estimated time on the tasks assigned. This way we have a reasonable tracking of progress since the estimated time is constantly changed to what the developer think is remaining. At the end of the sprint we can compare initial estimated with actual time spent and try to get better at initial estimate. You could possibly make updating the estimated time part of the daily standup. We started that way, but now it's up to each developer to update before the standup.

retorquere commented 13 years ago

Whether the time you spent decreases estimated time remaining with the exact same number of hours should be a conscious decision. Maybe a dialog could be added to allow you to change both at the same time, but automatically would be a risky assumption I think.

I see how it could confuse people since it deviates from standard redmine usage, but it's something people using backlogs will have to learn to use.

retorquere commented 13 years ago

This is not actually a bug but a discussion about a fundamental change in backlogs. I'd prefer discussions be held at http://forum.redminebacklogs.net/

bohansen commented 13 years ago

The dialog is there already - the feature "Timelog from taskboard" (can be enabled from backlogs settings) allows you to change estimated time while adding a spent time entry from the taskboard. Though it might be confusing that estimated time is an absolute value of remaining hours while the "spent time" field is the amount of hours added to spent time for that task.

jorgemorando commented 12 years ago

I encountered this same problem.

I think this discussion should not be taking place. Its a good (and standard) practice NOT to tamper with fields the framework to which a plugin is being developed for, SPECIALLY if the framework is actually using it. My point is, if the field is being used, a new db field should be created and shown somewhere in the view, so you wouldnt have the need to change the original information the plugin is using. I tried to solve this and thought about sharing a posible solution but afeter reading: "I see how it could confuse people since it deviates from standard redmine usage, but it's something people using backlogs will have to learn to use." i felt this statement was somewhat rude. Ergo, programming concepts should not be an issue. so i agree with closing this.

My solution to the problem after that was regretably to stop using the plugin in our office, untill Programming best practices are included.

Thanks for your efforts.

retorquere commented 12 years ago

Seriously, I don't know where to begin on this one.

For started, this issue has been addressed ages ago and the behavior you find so revolting is long gone.

And if you think it's rude that I should say that people will need to invest time to learn to work with it, I think it's incredibly rude that people say it's rude that software that I write for free for anyone to use comes on my own damn terms.

I don't regret for one minute that you stopped using the plugin. I've never seen any code contributions from you, so as far as I'm concerned you can take your theoretical "best practices" and shove it. It looks like you've commented on an issue long closed, for a problem long-resolved, just to thumb your chest that you know some industry lingo. Wow, look at you, all grown up.

Whether this discussion should or should not be taking place is something that the users that are looking to make a positive contribution can make very well without you.