Recently, I was asked these two questions by an Agile enthusiast who works with a services organization and have recently started practicing Scrum.
How do I know the budget without having to analyze all the features, especially when the feature list is too long and can’t fit in a sprint of 2 weeks?
The answer I gave was well received. Not because it was right from the process perspective but it was effective from the business perspective.
My simple point was: Who would disagree with the fact that processes and frameworks are created to serve the businesses and not otherwise?
Read on for the answers.
There is no way to know the budget without analyzing all the features. If the project is big and feature list is long then it gets even more challenging.
How to Deal With the Budget Problem When the Project is Big and Feature List is Long
- Analyze all your features
- Estimate the project as you’d normally do (using any conventional, non-agile methods that you’re comfortable with)
- Calculate one-month time-boxed cost of iteration. Refer to this excellent article by Jesse Fewell on the subject: How to Calculate Budgets for Agile Teams (Disclaimer: My entry in agile world is thanks to Jesse so I might be biased but his words of wisdom are way beyond any biases. Any Agile practitioner would vouch for his contribution in the world of Agile Software Development.)
- Now you have calculated your budget using two different methods. Use a variable factor to deal with uncertainty, that will come up
- This way you’d know how much margin you’re going to keep – now, you can make an offer that makes the business sense to your service company
When we execute a project using Scrum, the opportunity is to retrospect at the end of each sprint and ask ourselves:
- Are we going in the right direction?
- Did whatever we do in the past sprint is of any value from the business perspective?
- … and take corrective actions.
In theory, taking corrective actions means that you can stop developing further or pivot if the business value is not found in the delivered increment. Practically, many people (and companies) fear that practice. Which is normal because in business we need predictability although we know that life itself is not predictable. It’s agile!
So, business-people want predictability and budget is one such practical problem so rather than dealing with that problem using agile techniques, we can choose to deal with it using any technique that works.
Sure, since we’re considering Agile, we’d get the cost of iteration and add a variable factor to make some changes but it is, at its best, a kind of guesstimation.
This is not a perfect way. This is not where you will get optimum value from Scrum. Scrum framework is effective when the focus is on delivering value, not on finishing something by the budget.
If you can, avoid Scrum – or other agile practices – for these kinds of projects. If not, then you can tweak but in that case you’re not using Scrum – or agile.
Also in some cases, the clients of a service provider company would not much care which development framework the service provider uses. All what matters to them is how you will deliver the value. So make an offer to them that they cannot refuse.
- Is this Scrum? No.
- Is this Agile? No.
- Is this business? You know it better 🙂
In my opinion, when not to use Scrum is a distinction that every practitioner must have because then Scrum remains a tool, not a magic wand.
The war has to be won; does it matter if you win it using Swords or Guns?