I read and hear stories about teams struggling to size their work on a regular basis. While I have experienced this pattern before on my teams, it has been short-lived. The reason for this is that I tend to treat this issue like any other agile development effort. Try things fast and iterate.
I thought I’d take a few minutes of your time today to share some of my experiences in the hope that they might help you with this effort.
Why?
I can’t help but think that some teams struggle with sizing their efforts because there’s too much at stake. What do I mean by too much? Let me start with what I think sizing effort is good for:
Giving leadership some indication of the cost of delivering some value, such that they can evaluate ROI to determine if it is worth the effort.
Helping other dependent teams and individuals to have some idea of when they can expect progress so they can coordinate their efforts.
Providing the team with a benchmark to assess your own progress against your original expectations.
You may have thought of some things that I forgot and I’d love for you to post them in the comments. However, there are some reasons that I believe are agile antipatterns. Here are a few:
So leadership can assess the team’s performance
So leadership can compare teams to identify high and low performers
So other teams can blame a dependent team for not holding up their end of the deal
I’m sure there are more, but hopefully you see a pattern here. When estimation is used to judge a team or blame them, trust is eroded and we all know how important it is to maintain high levels of trust. This also explains why some teams stress so much about getting estimations right. There’s a lot at stake!
We all know that there are a million things that can derail an estimate. Unknown unknowns that were way bigger than anyone could have imagined. Changing requirements that have a large impact on scope. Personnel changes including departures and unexpected absence. The list goes on. Agile teams learn to manage the things they can control and go with the flow when they can’t.
How?
The key to dealing with the many things that can derail an estimate is to communicate early and often with as many people as possible. Giving others as much time to react to a changing situation is really the best you can do. If timing is critical, then maybe you’ll need to make scope adjustments, but the more people who know about it, the more input you can have into making the right decisions.
One of the biggest challenges with sizing work that I have witnessed is that there are usually people with different skill levels and familiarity on the team. Mobbing and pairing are great tools for mitigating this issue, but assuming you’re not using these regularly, you need to consider how you will factor this into your estimations. I love the idea of under-promising and over-delivering.
To effectively do this, consider ways to estimate based on the likelihood that at least some of the work will be picked up by someone who is low on the learning curve. They will struggle some on their own and likely need time from other developers to help them, which will distract the helpers from their own efforts.
The formula which I see most often is effort+complexity+unknowns=size. Our brains often resist this formula, but more often than not, it works. We’ll use the standard fibonacci sequence for story pointing as an example here. Let’s say the team thinks a story will take 2 points of effort. They also acknowledge that there is some moderate complexity in there and some new things that could have unknowns. In this example, we go to the next level for the complexity, taking us to a 3, and then we go to the next level for the unknowns, taking us to a 5.
Now, team members are going to look at this and think, “it’s a 2! Why are we calling it a 5?” The reality may be that it actually turns out to be a 2. Great! You’ve under-promised and over-delivered. However, more often than not, it is a 5 and the system works. Maybe the complexity wasn’t an issue but the unknown was bigger than anyone could have anticipated.
Iterating
Whether you use planning poker, forced ranking, the member with the highest estimate wins, or something else, what matters is that you’re not married to the approach. If you are regularly evaluating your effectiveness, you can always change approaches if the one you’re using isn’t working.
How will you know? I suggest two metrics to watch:
Average days from start to done for each size level
Standard deviation within each size level
Hopefully, you are using a tool like Jira that makes this easy to capture the average days as well as the data needed to calculate the standard deviation. With Jira, I find I can extract the necessary data to a spreadsheet and do the needed calculations.
This data tells me if there is a good relationship between levels, i.e. smaller stories are taking less time than larger ones. It also establishes a team average of actual elapsed time for each story size, which is helpful when sharing estimated time to completion.
Keep in mind that due to the nature of product development, these numbers mean little to nothing when evaluating a single or few stories. However, it can be very useful in looking at your work in aggregate over a significant amount of time (yes, I’m being vague here because you’ll need to decide for yourself what’s reasonable for your team).
The standard deviation is very useful for understanding how to pad your estimates when you communicate them to others within and outside the organization. It also gives you a clear way to identify outliers that are worthy of examination for learning opportunities. Were these stories subject to one of the many special circumstances that cannot be anticipated, or was there an opportunity missed to have more accurately estimated the work?
These two metrics are enough to identify opportunities to improve your estimating abilities. You should be reviewing them regularly to ensure that you are continually improving your capabilities. It is, after all, what agility is all about.
Comments