4 ms·

I’ve led a couple software teams so I’d like to think I have a bit of perspective here. The author of this article means well but this entire line of thinking i

I’ve led a couple software teams so I’d like to think I have a bit of perspective here. The author of this article means well but this entire line of thinking is flawed. For one, if you start using your story points for velocity tracking, people are gonna get wise to that pretty fast and start gaming things. That 5 point story? Looks like an 8 pointer to me. That quick task that needs to get done? Fuck you. Point it first and make it a 5 just in case. Oh my story is not fully tested? Fuck you. Merge it. Last day of the sprint. You’ll never get an honest accounting of work output this way. The incentive structure is totally wrong. If velocity is off, it’s YOUR fault as a leader. Not the teams. People are not CI jobs. You have to listen. Pay attention. Your job isn’t to make sure they’re productive by putting together these bullshit metrics. It’s to make them more productive by removing blockers and being a meat shield for misguided stuff like this.

pschuegr 3y ago
I think he kind of covers that by having first pass estimates done by the TL and having a rubric for complexity. Granted that metrics are dangerous, this seemed like a reasonable stab at solving some of the problems (assuming it was done carefully). Of course, it's no substitute for hiring the right people and having a less anxious upper management chain.
- localghost3000 3y ago
  Estimation and story points are a planning tool. You use them as a way to plot out your road map and prioritize initiatives. The minute you tie them to employee performance, you've obviated them for that purpose. Now the only thing people will care about (including your TL's) is making sure they keep their "score" inflated. Like I said, perverse incentive structure.