This is just terrible observation/philospophy/advice on so many levels. The idea you can apply the statistics used in an unambigous game like baseball to softwa

This is just terrible observation/philospophy/advice on so many levels. The idea you can apply the statistics used in an unambigous game like baseball to software development, even the idea they work in baseball beyond one example, that velocity is the metric that somehow counters all the issues with every other metric, that velocity can be attributed to a single developer... the list goes on. Using a 1-5 scale for effort estimation should be a huge RED flag. It shows the author does not understand complexity and required effort do not scale in a linear way. >> Break down large tasks into smaller subtasks, each of which can be easily scored using the above benchmarks. ...except it's the breaking down which is the hard part; this is not easy. Then adding all the sub components back up? This assumes there's no cost or effort; it's like saying lego kits assemble themselves. >> every two weeks during my 1:1 discussions with each engineer, I would also pull up that individual’s personal velocity chart and use that to guide our performance discussion. This is the definition of turning a 1:1 into a status report. The author would be better served by figuring out how to actually run a 1:1 rather than build a system where "Our methods certainly aren’t perfect and their flaws are obvious" >> Velocity can then be quantified at both the individual and team level, by calculating at the end of each week the number of points that were completed in that week >> Because the above methods are so widespread... No, this is not a widespread method, and totally flawed premise. I've got news for the author: velocity doesn't measure progress, and it's not some sort of proxy for how much stuff Developer A finished vs. Developer B. At its best it shows if the team is getting better at scoping stories over time. At its worst you get garbage like this.