“Better roughly right, than precisely wrong”
Plenty of teams still use hourly estimates for complex work. In my experience this always hurts. I thought plenty was written on this, but maybe some summarizing of what I have learned over the years might help.
Relative estimation: takes less time, focuses on team collaboration i.o. relying on individual expertise, we are better in relative estimation than absolute estimation, it helps drive cross-functional behavior, it enables output measures that can be used for forecasting, there is nothing like ideal time from the perspective of the person asking and giving the estimate, we use the power of the people: together we know more, it removes the pressure to be perfect (and the justification game towards the original estimate).
I do however understand that teams might struggle with how to use such an abstract measurement. Teams are still often required to give cost estimates, as well as do billing on actual hours spend. Customers and stakeholders still want answers on when something gets delivered. So proper planning and forecasting and different ways of budgeting might be needed.
The struggle with getting started
What I see that teams still struggle with, is using a good reference item. Maybe this approach might be helpful in your situation as well:
- Look at the last few sprints to the work you did, and use items are done for this exercise
- Talk through the items, to get it top of mind what the work required entailed
- Think risk, effort, complexity
- Hang the Fibonacci based cards on the wall as ‘buckets’
- Divide the items over the buckets in silence in a one-by-one manner
- You can put an untouched item in a bucket, or move an item from one bucket to another
- If an items moves more than 3 times, you can have a discussion about it
- In a matter of minutes you now have your relative estimates for the work you have done in the last sprints.
- From these items pick two items that will serve as references, to estimate future work
- I prefer picking an item of size 2 and one of size 5. This enables triangulation, there is still something smaller possible, and it helps for delivering smaller chunks of work.
- Use this to estimate the items on your backlog as a team.
The struggle with using relative estimates for Sprint Planning
Before we just looked at capacity and we could add hours, and we would know when we are full. Now we have no idea how much work can we pull in the Sprint? Maybe this simple description will help:
- Keep track of your output every Sprint, and let the past be the indicator for the next Sprint
- Use the best and worst case scenario’s to determine the bandwidth for your Sprint
- Always have a discussion and let the data be input / not leading for your decision
- Don’t forget to take into account things like holidays and other planned leave
- If you don’t have historical output metrics yet:
- Use your gut first
- Use the sum of ‘done’ items you used for picking the reference from the last Sprint
- Inspect and adapt, if you focus on really getting stuff done each – you will become more accurate in forecasting the amount of work you can handle
The struggle to answer those difficult stakeholder questions like ‘when do I get what?’
Many times I have heard, we do Agile now. We don’t know when we will finish this item. This could be interpreted as embracing complexity, but what can you tell your stakeholders then? We will get there, when we get there. Having no answer at all, to the question when do we get what, is not acceptable either in my opinion.
You can’t run a business, make decisions, manage stakeholders and just expect everything to turn out right. In many cases, stakeholders before had some idea of when they would get what. That plan might have been incorrect, but at least there was a feeling of being in control. So in some way, without lying, with empiricism, you should be able to give an answer to this question: “when do we get this?”
No you have had a few Sprints of a working product, you have an output measure for each Sprint. Now you can start to forecast. Using the actual data of how much work you can get done each Sprint, trends and scenario’s can be made. With some simple calculations you can determine worst case scenario’s and best case scenario’s. Based on our worst-case and best-case output measures, you will get this item somewhere between time X and Y.
Of course the world changes, of course new items will pop-up. That is why you have to have this conversation regularly. Every Sprint Review, you need your stakeholders to inspect your product, and look forward to stuff like this. Have a conversation about it, talk about the impact of scope change, the impact of interruptions, collaborate on the stuff that is hindering your team to go faster.
The struggle with the appearance of a lack of planning.
One other question that I often encounter is a more elaborate version of when do I get this? It is about when do we get what? We want to see a plan. The Product Backlog is your plan! That is why it is so important that it is transparent: so up-to-date, fully ordered, in language the stakeholders understand and open for them to see.
When Product Owners are not in the driver seat with a clear vision and roadmap, this lack of direction will be filled in some other way. Maybe it will be someone else making the call, maybe it will be a lot of politics, maybe it is continuous questions about when do we get what?
All those questions will gradually disappear when the collaboration moves more towards value / towards outcome. To move that conversation often requires at least one thing – a bit more trust. Or to put that the other way around, start showing some results and start having candid conversations about how the product is evolving. When you show you can deliver working products every sprints, it becomes a lot easier to get a grip on these questions.
The downside of hourly estimates when it comes to billing
In the recent years I have encountered several companies and teams that rely heavily on hourly registration behind the fact. Teams that have to justify every 15 minutes of what they work on. Teams that translate story points to hours, and then within the Sprint book on each item a person is working on. I have had a period at a previous company where I had an hour-code for booking hours.
In a project setting where people worked for different projects as individuals, this might have worked. When you have stable agile teams, and work moves to the teams, this becomes a burden. This request for hourly estimates upfront and precise registration after, in my observation results in:
- More analysis paralysis
- We look for upfront certainty, slow down, get stuck
- A focus on cost instead of value
- Individual behavior instead of collaboration
- My estimate, your issues, my progress, my sprint is done
- Aversity to change and the user
- Focus on output instead of outcome
If you let go ‘hourly billing’, in many organizations you need an alternative way to answer the question what is this going to cost me.
The struggle of answering ‘what is this going to cost me’ with relative estimates?
In organizations where there are different people, clients or business units paying the team, teams sometimes struggle. The go-to solution is to do precise estimation upfront, and then consistently report back against those hourly estimations. Precision is key here!
I can understand, especially at the start of a transition period, that it is hard to say: One Product Owner to make all the calls, whilst still different people paying the bill. So what can you do? Here are a few basics that I like to start from:
- You know what a team costs each Sprint
- e. 10K
- You know the worst and best case scenario what a team is able to deliver each Sprint
- e. 5 units and 10 units
- You thus know what the bandwidths (budget) for a specific estimated item will be based on that measure
- e. 2K <> 1K per unit of work
- In hindsight you can calculate based on the actual output measure that sprint what specific items have cost
- e. 8 units of work = 1.25K per unit of work
Maybe try this, see how it benefits the team and the stakeholders. Is this helping, then continue or take another step towards a leaner approach to estimation and billing.
Note: I am not a fan of this, since this still in a way looks and feels like ‘IT teams’ are a cost center. The discussion is still about what does it cost, instead of what value do we deliver. I rather have stable teams with people that simply earn a salary, and then move the discussion towards value. How do we make the best choices in around the work that we do. How do we get the most ‘bang for my buck’.
The struggle with the other ‘buts’
It is always easy to come up with plenty of obstacles in doing this. So just a few of these ‘buts’ to relative estimation and billing, with a potential reply..
But, then how do we deal with the Scrum Events, they are not specifically for a stakeholder right?
Are the events not in support of delivering value for your stakeholders? Why not spread these costs relatively? Might be a good time to inspect if they are really necessary if it is a lot? Otherwise, you could always use a buffer for these hours.
But, we also have other non-billable work, like company meetings and guilds. But, we have to deal with incidents too!
Same answer: Spread, kill, buffer
But, our stakeholders want certainty upfront.
Whether you estimate in hours, or relative in this manner – it is always an estimate. Are they at Reviews? Are you showing them working products? Have you tried something else? The proof is in the pudding.
You are not the first to struggle with these questions. When you are willing to give it a try – you will figure it out. Think solutions, not problems!