If after three or four sprints you notice your velocity is not where you had hoped it would be, do not panic. This might happen, this is why you need to set expectations accordingly and told your client not to trust your initial plans. The good news is that by the time you know about it, you can adjust course as necessary.

Being flexible about scope is the preferred method for restoring balance.

The important thing is to have the conversation and give your client some options. Yes, this may make you uncomfortable, but you can’t hide this stuff. Bad news early is the agile way.

There is one strategy for ensuring that when you do have the “too much to do, not enough time” conversation:

If you can’t deliver a minimalist version of the application with the time and resources you have got, then the plan is clearly wrong and needs to change.

It works like this:

1. take one or two really important features for your project (something core that goes from end to end through your entire architecture) and
2. measure how long it takes to build a minimalistic version of those features

Then use that against your remaining relatively sized stories to see whether a minimalistic version of the application is even possible with the time and resources you have.

If your dates are looking good, right on, if your dates are looking bad, great, at least you know about it now.

When you need to change the plan conversation from, It is not based on wishful thinking. There is no need to get emotional, it is just the facts. It is better to know this now than later.