I like the idea of technical debt - and think this is overlooked if you think of agile as top-down. Say if dev produce code that technically ticks your boxes,

I like the idea of technical debt - and think this is overlooked if you think of agile as top-down. Say if dev produce code that technically ticks your boxes, but they think there's an issue/oversight. Ideally you'd pick up the flaw, but letting them create an issue to track it is really important. Opportunity team (as I'm embracing the methodology) should take this debt as inputs, in the same way they would a screaming customer or pointy-haired-boss's ppt. #edit - If somebody commits to deliver something by end of sprint, I want to see it end of sprint. If they need to work the weekend to do it, then they work the weekend (and yes, I do know I sound like a dick). The reason why this is OK, is that commitment should only ever come from dev. I might like it to be done in a day and have no idea why it will take a week, but if I'd told it will take a week, it'll take a week and that's what does onto any projection.