Project managers normally add extra time to the estimates from developers as a contingency to come up with a project delivery date. This post looks at a different way of adding contingency – by having a subset of the desired features classified as definite deliverables, and another subset as possible deliverables.
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”
There is an alternative way of adding contingency into the project plan, without encouraging the development team to work more slowly. The AgilePM programme encourages the project to have a fixed delivery date and allow contingency in the feature list. This is done by prioritising the desired functionality using a MoSCoW approach (Must, Should, Could, Won’t deliver). Each delivery should have around 60% must, 20% should and 20% could features. The business stakeholders decide which functionality falls into each category, although it is helpful for you to set some definitions like:
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 definitions will depend on what you are developing, who it is for, and whether you are creating something brand new or a replacement for an existing system or process.
The clever bit is about how you set expectations:
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.