Story Points over Ideal Days?
Many teams going into Scrum, have internal debates around whether or not moving to Story Points or sticking with Ideal Days. It seems that there is a lot of personal feelings involved.
Ideal Days – what is it all about?
Just imagine a work day without any meetings, phone calls or people bothering you. It’s a full day of making things done, full day working solely on your tasks, whatever that means.
Story Points – what is it all about?
Story Points are a bit more abstract notion. It includes 3 parts: Work Effort (how much effort the work will take), Complexity (implementing known yet complex code) and Risk (3rd party integration, POC required etc). It inherently abstracts away the “who” to allow you to consider the “what”.
Estimation is expensive
I’ve said it before – estimation is expensive. You should find ways to make your estimation faster, unless you were specifically required to execute the Feature or bringing a super detailed estimation. If it’s not the case, and you were asked for numbers to determine Product Roadmap or feasibility of features, stick to fast gut feelings, may it be private hunch or collaborative hunch.
Fibonacci size – what is it all about?
To make estimation faster, it’s easier to have smaller list of options to pick from. For example, instead of picking a size from 1-100, you should pick from a smaller numbers range, like Fibonacci: 1,2,3,5,8,13 and then go to 20, 40, 70, 100. Why the jumps? Because the bigger the estimation, the bigger likelihood of being wrong or wasting too much time discussing how wrong. So instead of arguing on whether it’s 6 working days or 7, you just pick 8 or 5, depending on the specifics (effort, complexity, risk). The purpose is to estimate fast, not to be 100% precise.
Using Anchors
Usually, the idea is to price Features (or User Stories) against other Features *like* them. “This feature is around the same effort as that feature so it will be 3 Story Points as well”. After picking a few Features as “baseline”, it’s easier to estimate faster others features against them.
Ideal Days baggage
I personally believe that Ideal Days brings too much baggage into the discussion (making estimation slower):
1. Who’s Ideal Day? How long is one Ideal Day? Each member will consider her/his Ideal Day. Instead of focusing on fast estimation, everyone passing in their head “well, Joe is new in the team, it will take it twice as much! Let’s price it as twice as much then”. Story Points “don’t care” who is implementing the Feature. This is exactly how it should be done as you never really know who will actually be the implementor until you start working on it.
2. Ideal Days are not strongly correlated with estimating Complexity and Risks: People have in mind, when using Ideal Days, mostly effort involved. Story Points, due to its abstraction level, allows better focus on Complexity and Risk.
Matter of flavor, I guess
Anyway, I feel that it’s not really important whether you’re using Story Points on Ideal Days, as long as you (1) remember to price Complexity and Risk as well; as long as (2) you understand that estimation is expensive. I feel that Story Points offer better abstraction which allows faster estimation, but it’s really matter of “whatever works”.
Write down Estimation Reasoning!
Make sure you keep your estimation reason. “We said its 5 Story Points because it’s ~3 Story Points for effort and ~1-2 for Complexity and Risk. We felt good enough with 5 Story Points.” Why? If you would like to use this estimation as an anchor in the future, while trying to estimate a new feature, you should remember what the original 5 Story Points meant for you: “Was it 5 Story Points only because of effort?”