There are three important items to take into consideration when planning a product, or an iteration of that product.

• Budget
• Due Date
• Scope

It’s been said you can pick any two of these, but you can’t have all three. If you want it on budget and on time, scope will have to yield; if you want it on time and will full scope, the budget will have to yield, and if you want it on budget and with full scope, the date will have to move. This isn’t wrong. Having all three of these properties fixed will almost invariably result in a failure to meet at least one, if not all three. Each of these properties pushes against the other two. If Budget, Date, and Scope are all fixed and immovable creates the so-called Iron Triangle and limits the Development Team’s ability to successfully deliver a high quality product.

In most cases, budget will be pre-determined for a product (or iteration) and the Scrum Team will not have much flexibility on adjusting it. That leaves Date and Scope as items that are completely within the Scrum Team’s ability to influence. This is where good estimation and solid knowledge of the product become crucial.

I’m already on record of saying that I am completely on board with estimating our work, even if those estimates are fairly broad in nature as we look out across the Product Backlog. The large numbers in our Planning Poker decks exist for a reason, and should be played when we are attempting to scope entire features that we don’t have much information about. Relative sizing is important, and we don’t have to be accurate when “close enough” will suffice.

Knowing the team’s historic velocity will allow us to take those raw estimates and project out when we think we might have a release candidate with all of the desired work in scope. Using a release burnup and building in a cone of uncertainty to project forward when we might see completion of the work will assist you greatly here. Once we know approximately when the work will be complete, we can negotiate date and scope with stakeholders to determine which of the two we have flexibility on. The Product Owner should have a great idea of what her Minimum Marketable Features are for the product and take that into consideration, as there might be ample material that can safely be moved out of scope. It might be that your stakeholders are willing to wait a bit longer to have everything they desire in a release. Only through having that conversation can we know for sure.

Don’t get trapped inside the Iron Triangle. Leave some wiggle room in Date and Scope and, with Scope being the most likely to move, and you will find your team’s ability to succeed will rapidly improve!