As a project manager, Agile development methods such as Scrum are a great way of making sure that what you develop is relevant, and what the business stakeholders want/need. Typically, these stakeholders will see a basic version of the software very early on and can help guide the development to make sure the end product is as relevant as possible. This is the benefit of not fully specifying the solution up front - the ability to specify and develop iteratively based on what you learn as you go along.
However, without a full specification, it can be hard to make an accurate project plan. Developers will find it difficult to make accurate time estimates in advance on functionality that is not fully defined or even understood.
Traditionally, project managers take rough estimates of how long development will take, and add extra time into the plan as a contingency.
The downside of this approach is that the rough estimates of when it could be ready were on one date, and now as PM you are effectively telling everyone they can have an extra X weeks to deliver the development. The date with contingency is now taken as the target.
"To ensure on time delivery, add feature contingency rather than time contingency to the project plan"
- MUST = The business could not function without this feature
- SHOULD = The business could function without this feature but may be a backwards step (e.g. would take longer than now)
- COULD = The business could function in an improved way without this feature, but it would bring additional benefit
- The development team (who can continue to work in Scrum) will base their estimates on the entire functionality set: must, should and could. Their goal will be to develop it all by the delivery date (compare this to the time contingency approach -their goal was to deliver everything by the date + X amount of time, so they were aiming for later).
- The business will only be promised the must-have features. They agree, through the MoSCoW prioritisation, that this set of features is acceptable for deployment. Any should or could features that are delivered are a bonus.
Because the development team is aiming to deliver a lot more than the business is expecting, all that extra functionality acts as a contingency. Even if only the musts are delivered by the agreed date (60% of the overall feature list), this is still considered a successful outcome.
It is best to introduce must, should and could features into each sprint (or iteration, timebox etc). The features/tickets will be worked on in order of priority, so if time runs out, the least important things do not get done. Applying this at sprint level means you should accurately keep to the plan through the development period.