The Genesis of Real-World Sprint Estimating

In the beginning, Scrum defined the Sprint. And the sprint swirled and formed itself (usually) into a 2 week period of time. And the Delivery Team formed adjacent to the Sprint, and the number of the Delivery Team was 9 (a decent number, at least for the sake of this article). And Scrum said, “Eh, works for me” and smiled upon it.

And the Universe did The Math and realized that 9 (head count) x 6 (hours in a dev-day) x 10 (days per sprint) yielded 540 hours of work per sprint. And Scrum nodded and said, “Yep, looks about right.”

And The Backlog approached The Sprint and saw that its massive bulk could not fit within the confines of the 540. And lo, the Delivery Team realized that The Backlog needed to be broken into chunks which they then called “Sprint Backlog” because they hadn’t used the term Backlog enough and wanted to confuse outsiders.

And the Narrator caught himself and curtailed his digression.

And the Fundamentals of Project Management stepped into the picture and did its best James Cagney impression: “Ok, Devs, you’ve got Scope, Resources and Timeline to work with, yeah? And them Resources are fixed and so’s timeline with 540 hours. So where’s that leave ya?”

And the Fundamentals of Project Management paused, awaiting the inevitable admission by the Delivery Team: “All we can manipulate is Scope.”

And Fundamentals of Project Management smiled and blew the puff of smoke away from the tip of his gun barrel and sauntered away.

At this time, the Delivery Team realized it had a problem. Its so-called estimates, based on the direction of its Scrum Master, had been limited to Magic Beans called Story Points per that person’s training. And the Delivery Team was wise and sayeth unto the Scrum Master, “We need real world estimates here and we shall maketh those estimates in units of measure which allow us to determine which elements of the backlog will fit inside the 540.”

And the Scrum Master started to protest but was ignored.

And the Delivery Team looked upon The Backlog and saw that the Wise Product Owner had supplied Expected Behaviors from which they could derive well-formed Unit Tests which madeth their estimation task easy. And the team thought through the sequenced work and estimated based on expected hours to accomplish in small, digestible chunks.

And thus the Team set itself up for success and delivered code that provided Observed Behaviors that aligned with Expected Behaviors (because that’s the definition of no bugs).

And the Organization smiled upon this process and saw that it was good.

And they shipped code efficiently ever after.

#newagileparadigm #agileisntenough