Loading Profile...
Bugs and Chores should be estimable, without counting toward velocity.
Another thing I'd like to be able to do is *estimate* bugs and chores, but still have them *not count* towards the velocity.
When I add a new bug into the current iteration, I'd assign it an estimate of, say, 3.
Three corresponding points *must* drop off the bottom of the current sprint, right ? We have to let our customer know we won't get it all done and drop 3 points from our commitment.
Of course, when we mark the story complete it shouldn't count 3 points to our velocity, I'd say, but like a spacer image on a webpage it should have a size, and move something else out of the way.
When I add a new bug into the current iteration, I'd assign it an estimate of, say, 3.
Three corresponding points *must* drop off the bottom of the current sprint, right ? We have to let our customer know we won't get it all done and drop 3 points from our commitment.
Of course, when we mark the story complete it shouldn't count 3 points to our velocity, I'd say, but like a spacer image on a webpage it should have a size, and move something else out of the way.
I’m still happy
4
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company is considering this idea.
-
Inappropriate?Hi Alan, thanks for the suggestion. The idea behind the current model is that as long as the ratio of features to bugs/chores remains relatively constant, Tracker will predict release dates reasonably well, without the extra overhead estimating overhead, and multiple types of points (feature vs total). It is frequently the case, however, that as you get closer to a release, the number of chores/bugs in the backlog increases, and in that state, date projections become less accurate. At this point, though, you're usually fairly close to the release.
It is possible to enable estimation of bugs/chores (in project settings), but then you lose the important distinction between feature output, and total amount of work completed. Perhaps a simple change would be to display both the total and feature velocity. We'll discuss it in our next feature planning meeting.
Thanks again, and hope Tracker is working well for you otherwise.
dan -
Inappropriate?Hi Dan, Thanks for the feedback.
As I mentioned in my other post [ http://tinyurl.com/4df5wx ] I *love* Tracker. I've been waiting for someone to write this tool for nearly ten years (and tried myself a few times :-)
I think, in my head, I don't need to see both totals at the end. Features are the only thing that actually count. All a bug does is knock out our ability to deliver some feature in that iteration. It has a size therefore, but has the effect of reducing velocity. We had to drop this 3-point story because of this 3-point bug. This is assuming that bugs aren't planned in to the iteration, but surface midway.
This is an awesome tool. Please take my little nitpicks as just that. I've been living and breathing XP since 1999 so I'm not short of a humble opinion or two :-)
Thanks,
Alan
EMPLOYEE
