[geekjock]

The hard truth is that using velocity to measure performance will guarantee that developers bias their estimates to ensure they make themselves look good, thereby making your "estimates" useless.

Anyone who's built software knows that estimates are guesses and are bound to change once the work actually begins (not to mention if scope changes midway through).

Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning.

[mandeepj]

> Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning.

Your capacity is adjusted accordingly. In my team an engineer who's going to work-on production support, would not have his capacity accounted. Similarly, if an engineer has a lot of cross-team work going-on then we'll reduce his capacity as well, and so on.

[bosswipe]

Yuck, I'd quit your team. That level of micromanagement is demoralizing and it hurts the company. "Sorry support, I have zero autonomy. I can't talk to you unless my manager adjusts some number in some spreadsheet"

[mandeepj]

Sorry! I'm not doing it in just my team; that's how it's across hundred of teams in my org.

I believe I was not clear: it's a rotational support - where every engineer is encourage to spend a sprint worth of time in every quarter on working on support tickets. You've complete autonomy - you don't want to work on support tickets, it's alright. No one is forcing you. You want to spend next two weeks on a training or self-learning - go for it.

[AdieuToLogic]

  > > Your capacity is adjusted accordingly. ...

  > That level of micromanagement is demoralizing and it hurts the company.

The micromanagement identified is not in the type of work which is most appropriate to success, but instead in the "detailed capacity accounting." This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control).

Encouraging engineers to "spend a sprint worth of time in every quarter" or the "next two weeks on a training or self-learning" is laudable, but does not qualify as providing autonomy or the lack of micromanagement. The reasons why are A) the decision is still solely yours and B) clearly time-driven instead of collaboratively prioritized.

  You've complete autonomy ...

Not if you decide when, how long, and with what fixed frequency someone can work on tasks which impact "velocity."

[mandeepj]

Appreciate everyone joining the conversation!

> This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control).

I'm curious to know how it's done at your workplace. Please share.

[rufflez]

This is exactly what I would not want my team to suffer. They need to feel inspired, and those who are not inspired will know it themselves, and so will everyone they work with. I don't need a spreadsheet to tell somebody's commitment