> every sprint we either fail to deliver the work we commit to, or deliver work that ultimately fails the QA process > people seem to indicate everything is fin

> every sprint we either fail to deliver the work we commit to, or deliver work that ultimately fails the QA process > people seem to indicate everything is fine until 3-4 days before the end of the sprint. How long are these sprints? I wonder shorter sprints would help flag things earlier. Think about "velocity" as a metric to base sprint length on. How much wall clock time does it take to get a spelling fix into the release? Something that should pretty much always pass QA, peer review, etc. How often is your reworking a deliverable after QA fails it? Those two numbers should inform how you set sprint length -- long enough to get through the release process in the happy case, times enough iterations to reach that happy state. What are the daily standup status reports like? If you want earlier warning signs, I would suggest a three tier approach: Green, Yellow, Red. Green: deliverable is on track and expected to be completed on time. Yellow: deliverable is at risk, but a minor amount of additional information, discussion, attention or overtime can put it back on track. Red: deliverable is unlikely to finish on time and to spec. The thing you as a manager/project manager want to avoid is a deliverable going directly from green to red, as it means your team is unable to assess or react. It will probably happen with juniors and new teams, but your job is to communicate displeasure at the event, and coach them privately (during weekly 1:1's) how to avoid that going forward.