Seems like you have two different problems: 1. Fail to deliver work: It sounds like your prediction is simply off. Aim to have smaller sprints with stretch-and

Seems like you have two different problems: 1. Fail to deliver work: It sounds like your prediction is simply off. Aim to have smaller sprints with stretch-and-reach goals. I.e. "must haves" and "nice to haves". Really reduce the "must haves" to as much as you can get away with. The other good side to this is you can spin this towards "over delivering" a light sprint, rather than under-delivering on a heavy sprint. Also you might need to play about with the size of your sprints, if they are too long then focus is lost and things go off track without anybody noticing. If they are not long enough then you aren't really able ever to complete anything and the temptation to just push the task into the next sprint is too high. If a task being actively worked on does run over the sprint, never copy/move a task from one sprint to another, always make sure it's rewritten and refocused based on the progress and in light of difficulties had. Keep track of sprint planning and use some metrics to better estimate how much can be safely packed in. Track task estimated time and actual time, then look at the differences. You'll find some people have an optimism bias when calculating estimated time, ask them to factor this in. 2. Fail QA process: This seems like a failure to test the project extensively, unit tests are not enough. In the past we have implemented a code-freeze some time before the sprint-end/deliverable and then proper testing is done (sitting down with use-cases and going through them one-by-one), with only minor bug fixes allowed. NEVER allow last minute feature pushes, they WILL bite you. It's better to just over deliver in the next sprint when it's well tested. Usually (depending on the size of the team) this would be one dedicated tester and one dedicated bug fixer, with the other two people working on stuff that won't meet the sprint deadline but will be useful towards the project's goal (a great time for evaluating a few different libraries for example). General point: Say you get in at 8am, at ~9am (after people have looked at some emails) grab some breakfast and a coffee with your team for 20 minutes or so and plan the day. Just discuss some general points like "I'm going to keep working on X, progress is slow because I ran into Y yesterday". It just helps to keep things focused and the whole team know what's up. It's also good for morale.