Why using size to estimate tasks is better for agile

This past month my boss and I worked on a new contract for a current client. Even though our work with them is mostly Agile, and they genuinely understand it, our past contracts with them didn’t reflect that. Our past contracts were more rigid, and invoicing was getting harder and harder. For the past few months, we’ve been invoicing most of our work as “Out of scope”, but only because the work we were doing wasn’t technically part of the contract. But when does an agile project ever follow a rigid list of items?

So this time, we decided to do things differently. It was also the first time I contributed to the creation of a contract.

It all started with the client sending me a list of what they called IT Parking Lot and asking for estimates for each item. I made the mistake of actually meeting my team to discuss each item and come up with an estimate. In HOURS. My agile knowledge all gone out the window.

Luckily, before I could send those estimates, the client asked for this list to be part of the new contract. This is when I contacted my boss and he put me back on the agile track. This is also when we decided to make the contract Agile.

My boss was in charge of most of the contract, but I was in charge of updating the estimates for the items in the backlog. After a few conversations on how to handle those estimates, he suggested we keep it simple: S, M, L, XL, XXL (some items were just too big for L). It would be easier for me to estimate, and also easier for the client to understand. It also makes a lot more sense. Estimates are just estimates, they can be exaggerated, or most commonly, understated. This happens especially if the estimates are done in hours. By basing the estimates on the size and complexity of the task, instead of possible time worked on them, the estimates are more accurate and we won’t be making (time) promises we can’t keep.

During our meeting with the client to go over the new contract, these estimates helped us point out the flexibility we were trying to reflect in the contract. This list of backlog items and their estimates will be constantly changing throughout the contract’s duration, based on the stakeholders needs and priorities. So by having switched my initial estimates from hours to sizes, we saved ourselves a huge headache at the end of the day when these items (inevitably) change.