Agile principles are all about learning as you go and using the new knowledge to redefine the goals of the project. This is perfect for the developers and the immediately involved business representatives. But for a C-level exec it becomes hard.
Let us imagine that you and I are two C-level execs. I’m the CEO (yes, I get to pick first, because I write this before you read it). You can be the CFO and be even harder on keeping track of money than I am. In our management team there is also a CIO and of course some more C*O-people, but to make this story simple it’s just you (CFO) me (CEO) and the CIO that talks.
– I’ve got two interesting projects that would deliver lot of value to the business, says the CIO.
– That’s great, please describe what they are and the benefits, I reply.
– The first one is a trouble ticket management system integrated with the sales system’s backend. We expect that it would reduce the time for support calls by 50% on average by letting the support agents quickly find out if the customer is still covered by warranty or not. The second one is an improved supply chain management software that would reduce the number of spare parts we need to have in stock by 80%.
You (the CFO) gets eager:
– Our spare parts inventory is worth millions, so if you could bring that down by 80% it’s a huge one time profit. You never miss a chance to improved the numbers for the annual report. I continue to fill in:
– Reducing support call time is also a huge improvement. We have a hard time to find staff that are qualified and know enough about our products. Being able to use their time more efficiently would be great. We’ve got two great projects, I continue, that would give about the same level of benefits. Let’s see if we can afford them.
I (the CEO) turn to you (the CFO):
– What’s left of our investment budget?
– About a million.
– Ok, I turn to the CIO, how much do they cost?
As the CEO I am a strong believer of the full funding principle: If a project is launched, it will have the full funding required to finish. If that’s not possible the project won’t be started at all.
As the CEO I need to make a decision about the proposed projects. I have a limited number of alternatives.
- Don’t start any of them and save the money.
- Start the ticket system project, but not the supply chains one.
- Start the supply chains project, but not the ticket system one.
- Start both of them.
I would of course prefer to start both of them – but only if I know that the million I have left is enough to fully fund both of them. If both are not feasible, I would like to start the one that gives the best return on the invested money.
What I need at this point, that I ask the CIO for, is an estimate of each project.
How do we combine that with Agile principles?
The first and biggest problem is project scope. To be able to make an estimate at all, the scope of the project must be defined. To me, this goes against the agile principle of letting the requirements mature as the project runs and knowledge is increased.
The way I usually handle this conflict is to define the minimum scope of the project: What is the smallest thing that would still fulfill the project goals? Then I make an estimate for that basic solution, which will be the first version to be developed. During development requirements are refined and sometimes a new user story is added – but only if another one is removed. The scope remains fixed.
It works, but my agile heart cries.
The second problem that applies to some flavours of agile is that agile estimates tend to be relative with story points rather than absolute with hours. Relative estimates would do if it was a choice between the two proposed projects. But now it is also a choice between doing nothing and doing both. That decision is purely based on how far the million I have will take us. To be able to compare I do need absolute numbers.
Estimates are Required
Nevertheless I find the #NoEstimates movement extremely interesting as it questions if there are other and sometimes better alternatives than estimates.
#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, ways to make decisions with “No Estimates”.
— Woody Zuill
What do you think? Would it be possible to make the C-level prioritization without estimates? Please leave a comment below.