We finally decided to move from estimating in hours to estimating in Story Points, and we are quite happy about it.
It did take a while though, but in a meeting regarding if we should update our stories with time remaining and how to become better at it we started to realize that we shouldn’t. Estimating in hours sucks. Mostly because humans are really bad at it, we are always biased to optimistic thinking which means that even if you know that you probably will make a too low estimate, you will still make a too low estimate. So yeah, about 15 years of experience should at least give us the hint that estimating in hours is really bad, and hard not the least, and that we should stop fighting that Goliath and start doing something else instead. After discussing t-shirt sizes and such we just ended up with Story Points since at least a couple of our team members had some experience with Story Points.
So we now have a backlog with hours and want to start using Story Points, what do we do?
Formally, what we want to do now is moving from hours to complexity. Now remember that as of writing this is still a work in progress. We really want to look at our Story Points as a measure of complexity. But we have to start somewhere. The simplest way is to start using the time scale for the transition, so we started with 3 SP should equals of one day of work. We then converted the part of the backlog that was about Ready for Sprint. Then we just made some minor adjustments in the team to put the converted hours into the 0, 1/2, 1, 2, 3, 5, 8, 13, 20 (the somewhat-fibonnaci-scale).
Now we have SP in our backlog.
Next step is to figure out how we will estimate in the future. We decided to start with one or two sprints estimating in the new time scale, 3 SP = 1 day, and then start looking at 1) analogy, 2) complexity.
With Analogy we will look at reference stories, in the same sprint to start with, and later on we will be able to find a reference story that we can use, we just have to be accustomed with SP first. Don’t rush.
With Complexity we really are moving into an interesting domain. In the beginning of our journey I thought of complexity as “we have a complex development assignment in front of us”, but that is highly unlikely that your application is complex – in the formal sense. It is more likely that complexity will reveal itself as the domain of Unknown-Unknowns, or the the interaction of a team when really discussing or investigating just about anything. I don’t know where the term Unknown-Unknowns really comes from, but the references I know is Rumsfeldt and Dave Snowden in the Cynefin framework. While Rumsfeldt used the term to describe a hard situation where you actually don’t know anything, Dave Snowden is using it to describe a complex domain. The latter is why this makes things interesting. But I will now go into this right now. The Unknown-Unknowns might also be kind of related to the Johari Window, which is a similar 2-matrix where the Unknown-Unknowns is represented as What others don’t know about you – and what you do not know about you. In both models you need to explore what you don’t know, and reveal it to others.
Enough of that… just watch:
Cynefin Framework (intro) https://www.youtube.com/watch?v=N7oz366X0-8
Cynefin at Agile conference https://www.youtube.com/watch?v=-F4enP8oBFM
Johari Windows https://www.youtube.com/watch?v=KdYo5jn29w4
Back to Complexity and Unknown-Unknowns. If the team expects that the story to be estimated have a lot of Unknown-Unknowns, or maybe it is just a huge black box of which you don’t know anything, then you need to explore. The Complexity lies in not knowing anything about what you are supposed to do. This means that you have to explore, and you don’t really know how it will end up. This would mean a high complexity. But the complexity have to be in contrast with what the task is. If you don’t know what documentation you are looking for and don’t know quite where to find it, that should not be a 13 or 20. It is an Unknown-Unknown, but the question might be close. This is a simple and maybe dumb example, you will figure this our pretty quick anyway, it is just to mention that you will have to consider the amount of complexity. We will learn more as we go. I have even seen attempts to translate the Cynefin Framework into a idirect measure of SP depending on in which domain the story resides. But really, listen to Dave Snowden on the Cynefin Framework, both presentations are really good.
The other side of Complexity reminds us of Complex Adaptive Systems (CAS). CAS consists of interconnected, interdependent, adaptive and diverse agents. If you have made a really good job selecting your team you will have team members (interconnectedness) with different perspectives (cognitive diversity) that are working with related tasks and different technical toolboxes (interdependent) and that can adapt to the current reality and environment they work in to perform great work (adaptive). Then you will be able to have good discussions and dialogue. In our team we are working in pairs, and sometimes in group depending on what story we are working on. As the number of agents increase, complexity increase. Remember the four CAS properties I mentioned earlier, if you have a low amount of the four properties the system is almost ordered thus complexity is low, and the higher amount of the four properties complexity increase. This basically means that a high amount of team members (agents) working on the same issue will have a higher complexity than a lower number.
We have started to use this when estimating stories. If we need more team members to work on an issue where we have unknowns, then we will give these stories a higher SP. The cognitive diversity, different perspectives, will probably send us back and forth during dialogue, but in the end we will at least figure it out and everyone will have learned something new.
What is important to understand with this approach is that a complex story that two team members will work on might give the same SP as a less complex story that more team members work on. This is actually a property of using complexity in estimations that emerged during discussion.
I will write more on the Cynefin framework in coming blog posts.