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.

Task boards are fun for everyone!

User Story: As a new participant in an Agile world, I need to understand why I need a physical task board so I can make best use of it and not feel like I'm wasting my time.

Acceptance Criteria: Teams embrace the task board and begin to experience the results that occur with synergy.

In Agile we can use many different tools to help us track the work we're doing and provide our stakeholders with information. Many of these tools include a digital task board; this can be useful for teams, especially if they have remote team members or are a distributed team.

However, I coach teams to maintain a physical task board for several reasons. They can be a great information radiator for everyone interested in whatever you are doing--external stakeholders, other teams, managers, etc. 

A physical task board is also a good place to hold the daily stand up; gathering around this helps keep everyone focused on what we're talking about and makes very visible the progress against the commitment, or lack of.

 

But the main reason I coach to physical task board is because of what I call the magic. It's not really magic, but there is an effect that occurs for those teams that really embrace the task board and the benefits are many.

Generally, when I mention that having a physical task board--and holding stand up there every day--is a good idea and one I highly recommend, I get the questions. "Do we have to have a task board; is it required?" "Why do we need that and the one in the tool?" “Isn't that duplication of effort?" “Do we have to hold stand up every day?"

I always answer the same, “It’s up to each team to decide whether to have a physical task board. It is not a requirement and yes, it may feel like duplication of effort, but the synergy your team will realize as a result of that simple board will astound you. Try it for a sprint or two and if you don’t feel you derive any value from it, stop doing it. Oh and yes, you really should hold stand up every day.”

That’s usually enough for most teams to choose to try it; we can try anything for a couple weeks, right?

Some team members feel self-conscious and even embarrassed by setting up a task board. Writing their tasks on colored post-its and posting them in a publicly visual space and then standing there in front of it each day. This is so different from what we’re used to; even if our work is in some tool somewhere it’s not visible like this, where everyone can walk by and see or hear us talking about it.

But that is when the magic begins.

Some teams do the bare minimum and their boards may be monotone with the fewest columns and frills. Some teams really enjoy setting up their task board and making it their own in very creative ways. I encourage them to pick a theme or find a way to relate it to their team name, whatever matters to them as a team and is something they will maintain.

Then they plan some work, add it to the board, and start meeting every day for stand up. Their update to one another is accompanied by moving the tasks across the board and they begin to hold one another and themselves accountable to the commitment they made at planning.

As time goes by, and sprint after sprint is completed, team members begin to nudge each other to join stand up, they will relay their update to someone else on the team if they can’t make it, possibly email it if they know they won’t be there but the team needs the information.

They celebrate when tough tasks make it into the Done column, they swarm on tasks that threaten their commitment, and they work together to figure out how to divide up tasks when someone can’t meet their commitment for whatever reason. They begin to focus on the work, not who might be looking at them.

They stop seeing the color of the post its and the cartoon images on the board and see the work represented and how it progresses across the board; and in fact, want to show off their board and explain what they’re doing and that they figured out how to do something faster or more efficiently or with better quality.

Eventually, they become a cohesive team and OWN the task board they initially felt was unnecessary and a duplication of effort.

Synergy is defined as, the interaction of elements that when combined produce a total effect that is great then the sum of the individual elements. A basic condition for synergy is that the key players must effectively interact with each other.

Patrick Lencioni's book, the The Five Dysfunctions of a Team covers many of the issues that task boards address: "1) the absence of trust and openness among teams members; 2) fear of conflict; 3) lack of commitment to a topic or plan; 4) unwillingness to hold teammates accountable; 5) and inattention to results and lack of focus on the collective actions that must be taken." Task boards require that teams work through these things to optimal resolution and all in public.

Daniel Pink tells us that what really motivates people are autonomy, mastery, and purpose. The autonomy and purpose afforded by task boards lead to mastery of the skill sets, and/or the work we’re doing that is depicted on that board.

There are many and varied reasons tasks boards work so well.

I don’t usually tell people, but I call it magic.