> we either fail to deliver the work we commit to Given how hard it is to estimate software dev (for oneself let alone for a team), I think the speed with whic

> we either fail to deliver the work we commit to Given how hard it is to estimate software dev (for oneself let alone for a team), I think the speed with which your team produces quality code is more an emperical observation reflecting your team composition and dev/QA processes rather than a commitment you make. Especially so when the team is new and young. > or deliver work that ultimately fails the QA process How many layers of QA/QC do you have? For example, you can think of 4 layers: 0) spec/ticket/story author 1) code author, 2) code reviewer, 3) pre-release manual integration QA (by testers). These are very different activities (eg reviewer may not actually run code but could be able to tell by looking at code that something's wrong) with increasing cost of fixing issues at every layer. If you leave most of your QA to the last step you end up with a lot of hours spent fixing bugs while you could have avoided most of the same issues (and more) if, say, devs had clear instructions for testing their code and a solid review process.