3 ms·

I'm a big fan of agile, but I fundamentally disagree with some of the things you're suggesting. Developers aren't actually special snowflakes who must be defen

I'm a big fan of agile, but I fundamentally disagree with some of the things you're suggesting. Developers aren't actually special snowflakes who must be defended from the realities of the wider business, and they sure as hell shouldn't be hiding away work they'd like to do in what are nominally feature cards, what you're describing sounds more like the US legislation process of slipping funding for a coal power plant into a law which is designed to prevent discrimination so that the right person will vote for it. Trust is earned, and intentionally deceiving the product owner as to what they're going to get goes against that. A properly run and supported development team should be able to go to their product owner and make a convincing argument as to why they should be doing some work on paying down technical debt. If they can't convince the product owner in terms that are understood and taken on board that's a failing of the development team and the process they're working within. Or maybe the interest on that debt just doesn't outweigh the features that are being prioritised over it. In an ideal situation developers will be involved enough in the rest of the business to be able to see that without even bothering with pitching low value tasks as a priority. Equally my experience is that points based estimates don't really help anyone. The product owner is inevitably going to report to their management in terms that are more widely understood, namely time, and to do so they'll convert points into time. If you're lucky they'll use the current average rate of points/sprint to do that, if you're unlucky they'll just say 1 point = 1 hour and leave it at that. By extension that doesn't help the development team either, because they're doing estimates in points on the understanding that they don't directly map to time, and then get grief later when the points didn't directly map to time. Maybe I've just never seen Scrum done really well, and with sufficient buy in these aren't actually major issues, but my experience tells me no one is helped by adding a new language solely used for communicating the development team's plans and progress.

peteretep 10y ago
> Developers aren't actually > special snowflakes But generally, in a technical team, they're the experts on the technical stuff... > and they sure as hell > shouldn't be hiding away > work they'd like to do in > what are nominally feature > cards They should be mentally adding the postscript "in a way that leaves the project in a better state than I found it" to each feature, and estimating on that basis. That's their job. > then get grief later when > the points didn't directly > map to time If this happens at your workplace, either fix it or leave, much as you would if the promised health insurance your workplace offered turned out to be a spirit healer.
- jon-wood 10y ago
  I did fix it. I replaced the error prone practice of using units other than time for estimation with the far more understandable process of estimating in hours, days, weeks, and months. That comes with an understood caveat that as the units get bigger so does the margin of error, and if people want more accurate estimates they need to allow time to break the task down.

peteretep 10y ago

> Developers aren't actually > special snowflakes But generally, in a technical team, they're the experts on the technical stuff... > and they sure as hell > shouldn't be hiding away > work they'd like to do in > what are nominally feature > cards They should be mentally adding the postscript "in a way that leaves the project in a better state than I found it" to each feature, and estimating on that basis. That's their job. > then get grief later when > the points didn't directly > map to time If this happens at your workplace, either fix it or leave, much as you would if the promised health insurance your workplace offered turned out to be a spirit healer.

jon-wood 10y ago
I did fix it. I replaced the error prone practice of using units other than time for estimation with the far more understandable process of estimating in hours, days, weeks, and months. That comes with an understood caveat that as the units get bigger so does the margin of error, and if people want more accurate estimates they need to allow time to break the task down.