The crunch approach to sprints is the killer. If you know you can&#x27;t complete all the work in a sprint the answer should not be to bust yourself to try and complete it. Have a conversation with yourselves and the product owner to readdress what you can realistically achieve in the time remaining and then do that.<p>It&#x27;s a really hard thing to do, we all want to be the hero that saves the sprint. It also encourages you to end up with lots of discrete chunks of work in a sprint so you can complete 80% of your initial commitment and salvage a sense of achievement rather than getting 80% through a few big tasks but none of them actually done.<p>A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will almost never succeed. A sprint with 4 developers and 20 tasks each estimated to take a day or two stands a much better chance of success. Combine that with some metrics around &quot;complexity per developer per available day&quot; and you quickly end up with some charts showing productivity that is hopefully improving which will hopefully improve morale.