We'll respond shortly.
“Bugs and Chores don’t get points, unless you want to give them points, then they get points, but don’t point your bugs or chores.” Whaaaa?
In Tracker, you can (and should) always point your features. But you have to turn on this setting buried deep in the menus and next to a disclaimer if you want to point your bugs and chores.
If you’re looking for that check box, you’re probably a developer, or someone who is responsible for justifying the work of the developers. The business side has no interest in it what-so-ever. “Why?” That’s the right question.
The two of you (business and development) are trying to answer two different questions. Business wants to know how long it’ll be before they can release a product. As such, they have a set of features that must get in to a release. Doing anything aside from features, like chores and bugs, is paying down debt, and thus should be subtractive from velocity.
As a developer, you are less interested in when the business guys have decided to put a stamp on it and “go live”, you’ll still be developing just as much the next day anyway. You want to know if you’re getting better, faster, stronger as a team (we have the technology btw, just ask for Pivotal Labs!). Typically you might do an iteration or two with a lot of features, build up a solid velocity, push it to staging, and wait for the bugs to roll in. Now your next iteration is almost all bugs and your team is killing it, but Tracker says “0 points” and it kills you. “The guys (and gals) are doing all this work, and this will wreck their velocity”, you think to yourself.
Yes. But! Only their points completed for that iteration will be zero. Their velocity will accurately reflect their ability to deliver features over time. To better illustrate my point consider the following team:
If you fiddle with the number of iterations Tracker uses to compute the velocity, you see numbers like this at the end of the final iteration:
In this case, 11, from the average of the past 4 iterations, is the interesting number to most. It includes the bug part and the ramp up part. If your releases tend to be 3 iterations, you might consider making velocity an average of 3 iterations. If your releases are 15 iterations long, you might want to consider breaking them down into smaller releases.
By matching the number of iterations used to compute velocity to the length of your typical release, you should arrive at a very stable velocity for your team. This not only helps the business side predict when you can release, it also gives you something to point at when the financial guy wonders if the whole engineering team took the week off when you had a 0 velocity. And if he really grills you, you can always pop open Tracker and show the list of bugs and chores that were found by the other outstanding employees and how they’ve since been corrected, making the product better than it has ever been before.