It is common in Scrum projects to estimate your stories by using points, during the sprint planning. During my research for this post about story points I found a good article by Joshua Kerievsky called stop-using-story-points. I know.. long article (and I don't know if he is right) but he did find some familiar problems
When we decided in our team we wanted to start with points instead of hours someone introduced something called complexity points. Based on a theory he explained that this should work better. In this theory there is a complex formula to predict complexity of user stories. Long story short, we started using the term complexity points instead of hours.
Of course, this was difficult for most of the team. It took just a couple of weeks until we had some kind of formula where 1 points was equal to 1 hour. That was not working well :( After a few retrospectives and some adjustments the problems were solved by stopping talking about hours completely and just doing a couple of sprints. That's right, just by doing nothing particular the team learned and adjusted.
The other issue we did not foresee. Because we used the term complexity points I noticed that our team had started to have problems with the meaning of the word complexity. Complexity for most people mean how difficult something is, and that is different for everyone. On top of that, I received questions how we should estimate a story that is easy to do, but takes a lot of time. With the complexity points the estemation was only a couple of points but that would result in an unrealistic amount of work in our sprint. It was just not the right way.
When we decided in our team we wanted to start with points instead of hours someone introduced something called complexity points. Based on a theory he explained that this should work better. In this theory there is a complex formula to predict complexity of user stories. Long story short, we started using the term complexity points instead of hours.
Of course, this was difficult for most of the team. It took just a couple of weeks until we had some kind of formula where 1 points was equal to 1 hour. That was not working well :( After a few retrospectives and some adjustments the problems were solved by stopping talking about hours completely and just doing a couple of sprints. That's right, just by doing nothing particular the team learned and adjusted.
The other issue we did not foresee. Because we used the term complexity points I noticed that our team had started to have problems with the meaning of the word complexity. Complexity for most people mean how difficult something is, and that is different for everyone. On top of that, I received questions how we should estimate a story that is easy to do, but takes a lot of time. With the complexity points the estemation was only a couple of points but that would result in an unrealistic amount of work in our sprint. It was just not the right way.
It was clear to me that our problems came from using the term complexity. The word has such a strong meaning that we were unable to use it in a other context. Nowadays I coach our teams to estimate in effort or energy points. Those points are defined as (complexity X time) = effort. I ask the team to give their feeling on how much energy a story would take the team. That works much better.
So, what did we learn? Try to stay away from strong (subjective) terms like complexity in your Scrum. Make sure your team knows (and remembers) how the terms are defined and keep repeating that every planning session.