I know this thread is a little old now, but as a developer at Pivotal, I don't completely agree with any of the existing answers.
The philosophy behind not estimating bugs isn't that bux fixing doesn't deliver business value, it's that introducing a defect into the app and then fixing it does not represent net forward momentum.
For example, let's imagine ...
"Feature Velocity" vs. Capacity-Based Scheduling
Pivotal Labs is making a marketing decision with this design choice. By addressing themselves to "business value" as the key metric, they are implicitly discounting the importance of tracking team capacity or project scheduling in a broader sense.
Another way to look at this is that they are trying to sell a ...
You should estimate bugs and non-functional requirements
I am not familiar with Pivotal Tracker. However, looks like your question is more general:
Should I not be estimating bugs?
Should I not be estimating technical debt or non-functional requirements? I think this is what you are referring to as "chore".
In my opinion, you should be estimating these. ...
It depends vastly on several different factors, perhaps most importantly on which stage the Team is in in the 'Forming, Storming, Norming, Performing' process.
If the Team is in the Performing stage (that is, they're already performing at their 'optimal efficiency'), then I would expect velocity to be more or less static... when ignoring fluctuations caused ...
This is not a feature
Pivotal Tracker is a nice tool, however it lacks verbose permission and role functionality. Currently Pivotal Tracker only defines 3 specific roles for projects which are:
Account roles can be viewed here. At this time, one cannot describe what a particular role should have access to/capability to perform. For ...
Pivotal Tracker uses a rather simplistic permissions system that doesn't provide fine-grained technical controls. Process controls you impose on the the use of Pivotal Tracker by users with "member" or "project owner" permissions will need to be administrative rather than technical.
Pivotal Tracker Has Open Permissions by Design
Call me a purist but I would say neither. There should be no accumulated technical debt if you are doing Scrum right. Remember:
Individuals and interactions over processes and tools.
Regardless of tool, you must inspect your team and the work being done at the different Scrum events. Something must be really wrong if in spite of daily scrums, monthly (or ...
What you've created is technical debt, and it needs to be refactored.
Do not create duplicate stories, and try not to duplicate code as you just end up paying for things multiple times. A user story should capture the functionality and business value for a users perspective, if it has to be implemented on both legacy and next gen systems, then you could ...
I'll share some potential downsides, but I'd be hard-pressed to say this approach is wrong if it's working for you. There are some reasons that I wouldn't do it, but that's different than wrong. So here are a few potential downsides:
It sounds an awful lot like "getting credit". Only you and your team know if you're in that mindset, but I see a lot of teams ...
In reality most teams go slower over time. This because the bigger the product becomes the higher the complexity becomes. This as more and more parts are depended on each other.
To keep a high velocity you need to also practise good engineering practises, combined with refactoring to keep your code (c)lean and mean. Something project management tools do not ...
If you have to do it in 2 places, I see 2 tasks. Remember that what you estimate and track is the time a task takes, not how much value is got by the client.
And... yes, that duplicity is a problem you have to handle. You are consuming effort that is not translated in value for the client and PO should address it as soon as possible.
It can be used to identify long feedback cycles to shorten, impediments to be addressed, need for more shared understanding of items, large scope items that could be sliced more thinly, etc.
Cycle Time Report
There's a school of thought that says:
Don't estimate bug fixes, chores and spikes.
This is because points should only be awarded to work that adds value to the business.
Developers should be given an incentive to complete the most valuable work. They get kudos for burning down story points because those stories represent direct business value.
The simple answer would be if the team is working on an item then it should be estimated. As an example if the PO decided to run a technical debt sprint, addressing no new features, at the end of the sprint, if there was released software, why wouldn't there be a velocity for this sprint?
Work is work after all.
The only issue arises when a technical ...