I have a 3 part article on testing that I need to post... Regarding wasting time on 50% tests... it depends what your system is. In most of the systems (the no

I have a 3 part article on testing that I need to post... Regarding wasting time on 50% tests... it depends what your system is. In most of the systems (the no mission critical ones, no general libraries) I like to use the 80%/20% rule. I always ask: what are the 20% of the tests that deliver 80% of the value? You learn with experience but if you do not have it, this is a simple way to learn (as a team). During the sprint, have people write down: 1 - The tests that actually failed and found a real problem before the code was shipped. 2 - The tests you wrote for the bugs that were found in production during the sprint. If you haven't written the test yet, ask: what kind of test would have found this bug? Have people in the team share in the retrospective meeting. If you need more time at the beginning you can hold a meeting just for bug sharing. Discuss about the patterns. Commit to write more of these kind of tests. In a few sprint, you should see regression bugs going down. If you also take a look at the tests than never fail, you will also have a sense of the bugs you should not write. Let me know how it goes!