Wondering why Agile encourages task analysis (breaking large tasks into smaller tasks)? It’s all about accurate estimating and jelly beans. But mostly estimating.

Imagine a baby food jar. Now imagine it full of jelly beans. How many do you think are in there? 32? 64? 128? 256? If you’re like most people, you probably guessed 64. After all, a baby food jar’s not that big. And, like most people, you’d be close. The jar we used holds about 67. If you ask a group of people to each perform this estimating task, the group’s average estimate will be pretty close to the actual, with a small standard deviation. Translation: most people come pretty close to the correct answer, without a lot of variation from estimator to estimator, with this nice little jar of jellybeans.

Easy enough.

Now picture a jam jar. Not the super massive ones. The average sized jar of your favorite tasty preserves. But picture it full of jelly beans. Estimate again. You probably guessed 256. After all, it’s larger than a baby food jar, but it can’t possibly hold 512, right? Many people guess 256 and our jar holds approximately 186 jelly beans. If you got that same group together, the average of the estimates is usually farther from the actual than with the little jar, and the standard deviation is bigger, too. Translation: with a bigger jar of beans, the accuracy suffers and there’s more variation of opinions.

Now imagine a big peanut butter jar. How many jelly beans will fit in there? 128? 256? 512? 1024? Hmm. You might be waffling a little bit on this one. Probably more than 256, right? Can it possibly hold as many as 1,024? What does 1,000 jelly beans even look like? They’re tiny, but the jar is big. Maybe it can hold that many. It’s hard to decide. So hard that you might just give up altogether and pick a number simply to be done with it. Some stick with 256. Some choose 512. Some estimate 1,024. It turns out that our jar holds about 433 jelly beans. Only about 50% will choose the right estimate and the estimate itself is significantly different than the actual number…. and your friends’ estimates will generally vary a lot. Translation: the bigger the jar, the less accurate we are and the less sure we are of our guess in the first place.

So, back to Agile and time estimates. Which jar inspired the greatest confidence in your estimate? Probably the first jar. The teeny, tiny baby food jar. Our brains can picture a small volume. We are comfortable with small numbers. And it’s the same thing with tasks. It’s hard to estimate how long it will take to “develop a 45 minute course,” but it’s easier (and more pleasant) to think about “lay out the introduction screen.” That’s why we make small estimates when we use Agile.

Added bonus points: What would happen if you got to estimate the number of jelly beans in a jar 4 times a day, every day for a month? And each time, you’d find out the actual number of jelly beans. You’d get pretty darned good at estimating over time. When you make small estimates, you have to make more estimates over the duration of a project. When you make more estimates, you get more feedback about how good your estimates are and (in theory) you get better at it. Bonus all around!

This article was written by Instructional Designer Alison Hass.