I am no project manager, but I have been part of a few dozen different SCRUM systems over the years. Recently I had the pleasure of sitting in on a scrum where the SCRUM master was a bit frustrated because the engineers kept giving extremely conservative estimates on how long tasks would take. What I learned was that the engineers had been burned by estimating to low on tasks in the past and had picked up the habit of padding all their estimates so as to not get in trouble.

In the past we had a tool that helped the engineers communicate when they were unsure of a task's actual duration would likely be. Even better they could communicate by how far their initial estimates could be off by. They simply added a “Risk” score to each task. This does 2 things:

First allows them to give much more accurate estimates most of the time. Most tasks are a low risk typically. If you find that most of the tasks are a risk of nine out of ten then something is really wrong.

Second it allows the team to really dial in on where problems may arise in the project and address them before they become serious issues. For example if you find a task that is high risk you need to figure out how to mitigate that risk. If it is a big task, break it down into smaller tasks and then figure out which one of those smaller tasks truly has the most potential landmines in it.

From there you could figure out how long it would take to do a simple proof of concept with no polish or finish. Assign a specific duration then use that to calculate the cost of the POC or "Proof Of Concept"(Always figure out the effect of your decisions on the bottom line financially). Once you have that your team needs to decide based on the risk is it worth the gamble of building the POC.

A few years ago I was brought in on a project where a team of 12 or so developers, QAs, etc were building a software platform. The biggest requirement was that the mobile application could run offline and, when it came back online, it could sync backup extremely quickly. The team burnt through a few million dollars doing everything except working on that offline mode. Almost a year into the project they finally assigned one engineer to this feature. That engineer struggled for a few months trying to cobble together an offline mode before they eventually threw in the towel.

Had they assigned a risk score to every feature (and been honest about it) they could have figured out that the offline mode was by far the biggest risk early on and tackled that first, before they sunk several million dollars into building features that ultimately did not work when the device was offline which was the majority of the time.

Download my free e-book 20 Things You Can Do Today To Save Money On Your Amazon Web Services Bill