This article was first published on LinkedIn, on May 28 2020
Frustration with existing story estimation techniques
Story estimation is a difficult activity during the sprint planning ceremony. Over my career practising Agile, I've tried different methods to estimate stories so that we can accurately manage our sprint backlog. It was always frustrating to overestimate stories in a sprint and missing sprint goals. As a result, in order to meet sprint goals, engineers had to spend long hours and weekends to meet them.
While one may argue that it's not necessary to meet 100% of the sprint goals, and in fact, Agile considers meeting 75% of sprint goals a successful sprint, this won't work in teams with Asian cultures and in industries where there is an expectation to meet all goals that were promised.
For example, in the logistics industry, we are expected to deliver parcels successfully at an On-Time, In Full (OTIF) rate of 99%. Therefore, missing 25% of sprint goals is not acceptable.
What's not working?
Regardless of the technique you use, having a common understanding of the size of a story is not consistent. Sorting a user story to 8 or 10 or 13, is more a matter of gut rather than logic. Humans are really bad at differentiating the size of work. And no fibonacci sequence will help to differentiate between an effort of 10 and 13.
It then takes a few sprints to understand the velocity of your team and you gain a better gut to estimate stories better. So it may result in missing sprint goals and having to adjust the roadmap or insisting engineers spend longer hours and weekends to hit them.
Getting engineers into the right frame of mind
In order for engineers to estimate better, I got them to imagine that they are delivery drivers, and each user story is a cargo they need to deliver. As we are from the logistics industry, this allegory was helpful for them to also empathise with the user.
Using the t-shirt sizes as a basis for the Cargo-based Story Estimation Technique, I got the engineers to sort the cargo (user stories) into XS, S, M, L, or XL. They would silent read for about 20-30 minutes, and then ask questions about any cargo they want to talk about. And then recommend a size for that cargo.
Each size corresponds to a weight. We kept it simple and made it a number line corresponding each size to 0.5, 1, 2, 3, and 4. Depending on your measurement culture, you could use kilos or lbs. Whatever helps you have a sense of how heavy the cargo is.
In the physical world, I would paste the square post it notes over a card that corresponds to the size it was sorted in. In the digital world, I'd try to re-size the cards according to the size it was sorted in. So L cards would look a bit bigger than M cards.
Loading the cargo into the vessel
We then have another diagram of a rectangular box representing a vessel, like a delivery van or a cargo train. Below the box is a timeline representing the sprint. For beginning teams using this technique, I recommend starting with 10 kilos per delivery engineer which is about 1 small cargo per work day in a 2 week sprint.
Define the max capacity as the total number of delivery engineers multiplied by the max capacity per engineer (2 delivery engineers X 10 kilos = 20 kilos). This is your max capacity of the vessel.
Then I would instruct each engineer to load the cargo into the vessel from the cargo they will deliver first to the one they will deliver last from left to right. This helps engineers immediately visualise how they will execute the sprint. The Product Owner or Scrum Master can then assist to order the JIRA issues from top to bottom in the corresponding order.
If the total cargo is more than the max capacity, then we have to unload some of the cargo and place them back to the backlog.
Cargo-based Story Estimation Technique is insanely accurate and helps the delivery team
As a result of using the Cargo-based Story Estimation Technique, engineers feel more confident on delivering value to our stakeholders because they would be able to deliver an OTIF of 99-100%. In most sprints, we were able to deliver all cargo and meet our sprint goals. Sometimes, we may miss 1 or 2 small cargos and that's alright.
When you first start using this technique, you might underestimate the sprint backlog (runsheet). So you might deliver all cargo before the sprint finishes. My instruction to my delivery team is to pick any card that has already been estimated, and deliver them. This helps us know what is the true size of velocity in the team much faster than standard story estimation techniques.
Engineers who are exposed to the Cargo-based Story Estimation Technique has been extremely helpful in their work and they feel more productive, are less burned out, and feel more confident delivering quality work.
Another benefit of this technique is how easy it is to communicate with non-technical stakeholders. I can illustrate why that item in the backlog will take time to reach when I show them the max capacity and current load the team is delivering, thus avoiding jargon that only tech trained people might understand. This way, I use a common framework to communicate with all parts of the organisation.
In reality, delivering software is exactly like delivering cargo. It’s all logistics and should be as simple as getting cargo from point A to point B.
---
If you have questions about Cargo-based Story Estimation Technique, or want me to conduct a workshop or presentation for your SCRUM team about it, just reach out and we'll be in touch.
Photo by Ketut Subiyanto