Has the fibonacci sequence got you down? Do you often find yourself in refinement staring at the ceiling? Do you want to scream to the heavens “WHAT IS THE POINT of pointing!”? Well this blog is for you and (hopefully) will give you a fresh look at how you can estimate effort.
First of all, a quick refresh on why we estimate. Estimation drives discussion! Discussion helps a team determine whether the work can be done in a sprint or needs to be broken out. Discussion gets the team on the same level of understanding about what needs to actually be done and how. Discussion builds knowledge and empathy among your team members. Estimation discussions also helps identify dependencies. It can help the PO determine priority of the work based on value vs. effort. Estimation has a lot of value but at its core, that value is in driving discussions.
A lot of teams start estimating without knowing the why. They just accept that they have to do it because it is "part of Scrum". They use the fibonacci sequence because that is the most popular method. The trouble with this is, if teams don’t understand WHY you estimate, they often fall back on old habits. Pretty soon your fibonacci sequence gets translated to days and days get translated to stakeholders as deadlines. And you have a lot of unhappy teams back in time management practices.
So how do you break this cycle? How do you help teams realize the true value of estimation? These are some of the steps I took with my teams to get them out of a “time” mind-set during estimation and into a discussion driven habit.
The Fish Scale
I had a team that suffered from the issue of equating time to points and finding the exercise of “estimating” frustrating. When I explained what estimation was supposed to do, they were still somewhat confused. At the root of it, when they looked at the fibonacci sequence they saw numbers. Numbers translated to time for them. I got them to remove the numbers by translating effort into another scale. The Fish Scale. No pun intended.
The goal was to understand how different things have different levels of effort and complexity. We identified that the smallest fish in terms of effort and complexity was a Guppy. They took up very small spaces, they didn’t need much food, and were very easy to keep as pets (low maintenance). On the other end, we identified the Whale Shark as the largest estimate. It took up A LOT OF SPACE, it needed A LOT OF FOOD, and in general was a great deal more complex of a creature than the guppy. From there we filled in the gaps.
Now how did they show their estimates? We used hand signals. Since the sizes of each fish were relative in dimension, team members were able to hold up their hands in relation to the size. For example, the whale shark, the team member would stretch their arms out as far as possible. If a team member didn’t know how to estimate or thought it was bigger than a whale shark, they would throw their arms up above their head and that represented “drowning in the ocean”.
Having the relative size created visually by the team members helped them think of estimation in terms size instead of time. They also had fun doing it and we even did a team outing to the local aquarium to verify our scale.
Other teams have used a dog scale or planet scale. It really is up to the team to determine what method can drive the discussions around complexity, risk, repetitively, and size of the ask rather than time.
Side Note for Scrum Masters; if you use a tool like JIRA, to keep using the reports and fields, you will still need to translate whatever scale your team works into numbers for the system.
My teams generally start out doing this type of estimation then later on they have gone back to fibonacci but with a richer understanding of the value behind estimation and they get less hung up on 2 vs. 3. Instead they drive the discussion to know WHY someone estimated the way they did in order to gain understanding and come to a shared conclusion.