Who is this Fibonacci guy?

As an Agile Coach, I want to help teams new to Agile understand how to use Story Points to estimate their work so they can establish their velocity.

According to Wikipedia*, Leonardo Bonacci was an Italian mathematician, considered "the most talented Western mathematician of the Middle Ages." He introduced to Europe the Hindu-Arabic numeral system primarily through his composition of 1202, Liber Abaci (Book of Calculation). 

Liber Abaci posed, and solved, a problem involving the growth of a population for rabbits based on idealized assumptions. 

(Ed note: Wikipedia does not mention why this was a problem to be solved; we are left to surmise.)

The solution, generation by generation, was a sequence of numbers which came to be known as the Fibonacci numbers. The number sequence was known to Indian mathematicians as early as the 6th century, but was not previously known in Europe.

In the Fibonacci sequence, each number is the sum of the previous two numbers. Fibonacci began the sequence not with 0, 1, 1, 2 as modern mathematicians do, but with 1,1,2.

Because it offers a unique opportunity to compare by relative size, this series is commonly used as story points in the Agile world.

Story points are an arbitrary unit of measurement, unique to each team, used to estimate the relative size of a story. We could use estimates like small, medium and large to estimate stories relative to one another--and many teams do--but the numbers provide a way to measure how much work we can get done in a specific time period.

Here's how it works; teams select a story and discuss it to understand the work that must be done. Then they collectively assign story points to it based on the complexity of effort required to complete the story. They do this for all the stories they have in their sprint backlog; they compare stories to each other to find their relative size. 

Eventually the sum of the story points becomes the target velocity for that sprint. Say a team plans to work on eight stories that total 24 story points; when the sprint ends, they accept story points for the work completed and the resulting number is the team velocity. 

When the team plans the next sprint they use this number as a target for planning. If they completed 24 story points worth of work in the last sprint, they should target 24 +/- 2-5 story points in the next sprint, depending on their maturity and capacity. Eventually they can take the average velocity from several sprints to use as their guide.

There are different ways to assign story points; I coach teams to use planning poker because I like to steer them toward consensus in estimating. Consensus is one of those things that will move a team toward true collaboration rather than being a group of people doing some work at the same time.

In my experience, especially for teams new to Agile, a group approaches consensus much quicker using poker planning cards, as it helps to prevent one team member deciding for all or influencing the rest of the group. Poker planning also helps them get past the initial I'm guessing stage, because the different estimates spark the conversation the team needs to have that results in a shared understanding of the work and a shared estimate.

I am asked often why we don't estimate stories using time--how long will it take to complete a story in hours; and a related question, why don't we tie hours to story points.

There is a very good reason why we don't do this and Mike Cohn explains it with an interesting example. But the bottom line is different people have different skill sets and experience, and what will take one person 1-2 hours could take another 2-3 times that.

There is no right or wrong number in estimating and every team will have different estimates for stories, even those that may be similar in effort, because it is relative to the skill sets and experience on each team. 

I have found that teams may start out not really understanding what they're doing or how it works but eventually they grasp the abstract concept of story pointing and establish a velocity which they then use to understand how much work they can take on in a sprint. It becomes a good jumping off point for them to continually inspect and adapt their practices; for example, if we automate testing can we get more stories done in a sprint? 

I usually provide poker planning cards (similar to those in the picture above) for the teams I coach, but getting something shipped to us here in the Philippines can be prohibitively expensive. Lucky for my teams, I was raised with a necessity is the mother of invention attitude so I often suggest to teams that they figure out a way to create their own cards. This varies from numbers written on post its or index cards to teams creating their own sets of cards--as seen here--to teams using apps on their phones.

The good news is that if I can get teams to perform the exercise for one or two sprints, they usually reach the point where they understand the sizing within their team, establish their velocity, and start looking for opportunities to continually improve--which is where we want them--rather than spending time debating with one another what story points mean or whether they should be tied to time.

*Information borrowed wholesale and paraphrased from the information on the Wikipedia site.