在Scrum迭代过程中，比较看重的一点是最后的验收质量，迭代是滚动的，如果迭代的质量不达标，就会导致质量债一直存在，这样就会像滚雪球一样，逐步积累起来，越来越大，最终导致Scrum只有形而已，而不是真正的敏捷。因为不能在任意阶段拿出可以发布的产品。
而产品质量这个词汇，又是一个比较虚的词汇，谁也不能保证产品没有bug了，谁也不能说产品的质量到达一个什么地步了。另外一点就是在Scrum迭代过程中存在着三种角色，产品经理，研发，测试。在高质量的敏捷素质要求里面，要求后两者合二为一了，成为一个全能人才。但是很多公司里面，研发和测试还是割裂开的。那么这三个角色之间也会面临着质量诉求，研发要求产品经理的输出是在合理的质量范围，而不能在研发，或者测试的过程中发现问题。测试对于研发的质量输入也是有一定的要求的，不能出现太多的低级bug。这样就面临了一个质量标准问题。
最早的时候，是由上游说了算的，需求人员把文档交给程序员，告知完成了，程序员研发完成告知测试人员写完了。因为没有约束，所以导致质量不是很好，测试人员总是抱怨质量太差，测试的都是低级错误。后来进行实践，做过checklist（自检列表），然后根据测试的反馈进行了调整自测列表，但是即使这样，测试人员的满意度也不是很高，认为研发的输出质量依然不是很高，导致测试这边的压力很大。另外一点就是，公司里面的测试人员的配比很低，只有8:1或者10:1的比例，这样也要求研发的输出质量要高一些，避免上一个迭代的测试还没有完成，下一次的迭代输出就已经到了。导致测试永远都是瓶颈，也是压力最大的人员，也避免作为最后的一道屏障因为前面的输出质量太差，而纠缠在普通的bug上无法自拔，导致质量水平偏低。
针对上面的这些问题，参考了对日软件的经验和标准，制定了一套Scrum迭代内的质量标准。在公司的研发体系内，Scrum迭代内包括以下内容，详细需求，研发，测试。这样根据本次迭代的条目挑选出详细需求，进行研发，成果进行交付测试人员测试。三个过程都进行了约束，制定了质量标准。按照之前的经验，约定Scrum迭代内的质量标准为16Bug/KL（每千行代码16个bug），约定详细需求为4Bug/KL，设计+CD为7Bug/KL，测试为3Bug/KL。
约定了这个标准之后，要求研发人员需要找出详细需求4Bug/KL，研发后研发人员需要测出7Bug/KL的标准才能交付给测试人员，测试人员必须测试出3Bug/KL之后才能认为本次迭代结束。因为需求文档还没有对应的代码行数，于是根据研发时间进行估算，按照50L/D的天数进行计算。（按照生产性来说，应该是20L/D,但是因为现阶段的重复代码的存在，所以制定上翻了一倍左右。）这样按照预言的研发天数进行需求文档的质量约束。