>Reducing the scope of the sprint to something that should be very easy to deliver on The scope isn't your decision, it's the team's decision. They should only

>Reducing the scope of the sprint to something that should be very easy to deliver on The scope isn't your decision, it's the team's decision. They should only be committing to Do three things: 1) Track the work committed to work completed ratio. You want to goal this towards 90%. It's a great metric because it's not easily game-able and it serves your team's interest. 2) Make sure all tasks are broken down into small chunks (no task should be a >3 day worth of work task). If you have a developer who has 1 ticket for the entire sprint then your tasks are too big and need to be broken down. 3) Get the team to commit early and often. It sounds like right now you might be doing "mini-waterfall" whereas you want something more like Scrum. There should be visible progress on Day 2, even if it is just notes on what they are thinking through to implement.