18

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 ...


3

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 ...


2

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 ...


2

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: Owner Member Viewer Account roles can be viewed here. At this time, one cannot describe what a particular role should have access to/capability to perform. For ...


2

TL;DR 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 In ...


2

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 ...


2

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 ...


2

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 ...


1

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.


1

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


1

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. By ...


1

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible