Why do even Agile projects double in size? Enter "The Trapezoid of Torture"

You start your release planning. You do all the right things - align stakeholders, create stories, do planning poker with engineers.  Story Points on everything. You plug this great data into your release plan and produce the following lovely chart. 800 Story points should be complete in 9 Sprints. Perhaps you even say - "We'll be done after Sprint 9.  Maybe we'll need a Sprint for the release, so lets call it Sprint 10 in production."

A few days later the product owner comes back.  Delighted.  Loves the chart.  Showed it to the CEO, the Head of Marketing and the whole Sales Team.  Now there are another 73 stories and 500 more points for your backlog. Taking the total count to 1300 points.  So you sit them down.  You make them prioritize. Must-Should-Could  MoSCoW - too easy.  You plug this into the lovely chart with a few nice colors for the various scopes. Now we're looking at Sprint 15 for everything or Sprint 10 for the original Must Have scope.  So the Product Owner says - OK why not.  Lets build it all. I can wait 15 Sprints but no longer. Can you give me the whole scope in 15 Sprints?  Of course we all say yes.  After all the chart never lies.  Does it?

So you run your sprints.  You notice that velocity is not quite as high as planned.  Although no new stories are added the scope also seems to grow daily.  At the end of each sprint the goal posts seem to recede further.  Nobody wants to break it to the Product Owner.  Finally in Sprint 21, after the worst project of your life, the product finally goes live. 21 Sprints.  Twice the original time.  Why?

The answer to this problem is two fold.

Firstly everybody remembers the first 10 Sprints to Production statement. Even though you reset expectation, they harboured a hope and hung it on your first beautifully optimistic statement. Perhaps they also told everyone it would be done in 10 sprints but never reset expectation.  Whats a few extra sprints?

The second part is captured in the following graph.  We take the 1300 story points and create an optimistic and pessimistic line for each - adding and subtracting 20%.   These are the dashed horizontal lines.  The we take our velocity and we do the same - add 20% and subtract 20% for each point.  This gives a distribution of possible outcomes.  The earliest being sprint 10, with best (same outcome, less coding) and best velocity.  The worst case is around Sprint 21 which is worst velocity and bigger scope.  The distorted diamond that these lines create, I have called the "Trapezoid of Torture".  This represents the gap between best case and worst case.  The worst case is nearly twice the best case.  Many projects "double" in size due to optimistic views on velocity and scope.