Loading Profile...
EMPLOYEE
Why can't I estimate my bugs and chores?
5
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?This has been debated extensively, but here are some common arguments against estimating bugs and chores:
* Bugs and chores are a cost of doing business. Tracker's automatic velocity calculation frees you from having to account for this cost, and instead to focus your planning on business value, risk, and prioritization.
* The goal of measuring velocity is to predict how much business value can be delivered in each iteration. Therefore, only work which provides business value is given points. Bugs are not given points because the introduction of bugs actually distracts from providing business value.
* When there are bugs in features which have already been accepted, points have already been measured in the project velocity for that feature. Counting them again would be double counting.
* Chores should be thought of as engineering overhead -- not directly providing business value, but merely enabling the ability to provide business value.
If you'd still like to be able to estimate bugs and chores, you can enable it for your project in the project settings. You can disable it later, as long as there are no estimated bugs or chores in the project.
The company and 2 other people say
this answers the question
-
Inappropriate?I work on a Maintenance project which is another project from the original development. Bugs and chores is most of what we do for customer who provide customer care for end users that use online service daily. Thank you for this ability.
I’m thankful
-
Inappropriate?We agree with the fact that chores and bugs should not be part of the velocity. However, we think that estimating them is valuable because it still influences how much we can do in a cycle, whether chores or not. We still plan chores (we know about them when we start our cycle), and we also know that they do not (directly) add business value and should therefore not count as part of the velocity.
For example, we are building a website and had to change the way we render (using pure Seaside, moved to Magritte). In a way, it improves the system from an error handling perspective and paves the way for other enhancements (like adding history at a generic level).
We saw this change as a chore because it is difficult to explain this to the customer and we were willing to lower our velocity (*real* stuff a customer can see).
Any ideas on this thinking? Does this imply that we are doing stuff that the customer did not ask for & we should be convincing him/her that it is necessary, which implies explaining exactly why we are doing it?
I’m undecided
-
Inappropriate?How about both?
Let me choose on the fly whether velocitiy is just features (as my customer wants) or features+bugs+chore (as my maintenace team needs).
Thanks!
EMPLOYEE
