Please login or join to subscribe to this thread
There is nothing new below the sun. This topic has been covered by Barry Bothem long time ago. In fact, few people know the foundation of iterative-incremental life cycle is the Spiral model. At the same time Mr. Bohem took a model called Cone of Uncertainty and adapt it to initiatives to crea software products. Buth the cone is used and referenced by other domains. So, go to Mr Bohem work, mainly "Software Economics", and you will find everything you need.
One approach is to use coarse grained relative sizing (e.g. T-shirt sizing) to size high-level deliverables, features or themes. This will provide a ROM estimate which can be risk adjusted (if required) and used as a ceiling for development efforts. Another approach is to break the work into releases and only budget at the granularity of the very next release.
My main question is if the client accepts the lack of an estimate of the budget and especially if he pays the costs inherent to the project.
Rough estimate – is only an estimate and not final. No – client or the sponsor will never pay on estimates. What we normally do is budget is prepared as normally done for any project, with manhours estimated, this is done outside the sprint. We get the same approved by the client before the project beings.
This can vary significantly depending on your developmental framework, your relationship to your customer (internal to the business or external, contract type, previous work relationships, etc.) and the maturity of your team.
Estimates (guesses) can be very difficult at initiation, but that's true regardless of your development cycle. If you're starting from scratch, try to define an MVP and just budget for that. When it's complete, you can have conversations with your customer to decide what they want next, and you'll have some empirical data you can use for your next set of estimates. This reduces budgetary risk for both you and your customer.
Also don't forget that you can still apply the "triple constraints." If your budget has a cap, you can prioritize your work to make sure the most important features are completed before the money runs out. A good roadmap and burn-up chart can help you track and present this information.
Please login or join to reply