Practical Fibonacci-Part II

The Journey to Predictability

Julee Everett
Agile Insider
Published in
7 min readOct 21, 2021

--

Background photo by Giulia May on Unsplash with edits by Author

Agile transformations, in particular, Scrum, often tout “predictability” as a benefit. This concept is a critical component of success, and I find we don’t spend enough time at the beginning on how to achieve predictable delivery. It mostly comes through practice, but some organizations quit before they achieve success and then blame the Agile frameworks rather than changing their behavior or structure. Below are some common questions from teams starting their journey. (See Part I, Practical Fibonacci)

Coaching the gray areas

#1 Frequently Asked Question

“Assuming good record keeping of estimates and actual time spent, how many Sprints does it take before the Team can reliably size a Sprint?” Each team is different and is very dependent on “good Agile citizenship” influencing their workflow (i.e., no outside pressure, no interruptions, alignment on outcomes) and a healthy ecosystem (i.e., stable, sustainable, cross-functional teams, little or no dependencies). In the healthiest scenario, from my experience, it takes a minimum of three ‘regular’ Sprints to get into the groove. I wouldn’t count the first one or two, and I wouldn’t count holiday weeks. But it does happen–when set up for success and left alone to do what they say they will do, teams get good at figuring out what they can complete in a Sprint.

Humans are terrible at estimating (See Part I), so don’t assume you will ever get “good” estimates. (And spending more time estimating doesn’t make us better at it.) A better approach is for the Scrum Master to track team trends and use the Retrospective event to help the team get better at relative sizing and forecasting their Sprint plan.

Examples

Here are some examples of trends from client teams and the corresponding actions they adopted to improve:

The codebase has a lot of technical debt, therefore:

  • the Developers can do more refactoring and work on burning down technical debt
  • the Scrum Master can ensure the sizing includes all the work that is needed to get to Done
  • the Product Owner can make sure the efforts are limited to the…

--

--

Julee Everett
Agile Insider

Writer, reader, observer. People enthusiast. Overdoes bird watching and waterfalls, can’t pass up a good cup of coffee. Hails from NW Georgia.