The fundamental problem with scrum is that bugs happen and nothing interesting from a development point of view can be predicted effort wise before hand, at lea

The fundamental problem with scrum is that bugs happen and nothing interesting from a development point of view can be predicted effort wise before hand, at least not accurately. The right way, is to do all velocity analysis backward-looking. Create a culture where code reviews are done constantly and long after they've been merged in. Use metrics like KLOC, duplicate lines of code, changes to code, stories completed, etc. That's the way to measure velocity. Measuring done done done by end of sprint, is really wasteful as some engineers get it into their head to pad their estimates to make sure it's completed by some arbitrary date. This just leads to a culture of padding estimates rather than completing work when it's done. That said, I do like letting engineers pull tasks as they like. If a more senior engineer in a certain area can complete a task better and more thoughtfully, than he should have a chance to pull it. This also does require technical PMs which can discuss and understand the cost of their stories. This is important regardless however.