Project size estimations and then execution, are the burden for every Product Owner and Project Manager. Business always wanted to know:
Practical agile principles should empower the Business to:
However agile itself or/with microservices-hype seems not to fulfill entirely any above of demands. The main reason is that:
They do not take under consideration combined costs estimation, requirements gathering with repeatable method of implementation (with right design) and delivery.
It feels we should know by now how to process information.
It’s also said that you cannot precisely calculate project size/complexity and there isn’t anything like a cost per functional unit. We failed to define the unit - some attempts:
Those ways of estimation do not tell you (your team) how you should implement requirements nor how to naturally make sure Business understands what was ordered. And so Teams fail because there is too much uncertainty and we cannot construct a strict schedule.
On the other side, in Agile, user-stories (features) should be estimated relatively with story-points, where the measuring base unit is defined by the team. Then you cannot easily compare velocities from different teams/companies/on the market. Also you cannot estimate the whole project, only the next iteration. You may allocate resources for cetain time and periodicly check velocity of the Team.
In software-house’s practice however, a min/max estimation is usually done - you might argue that it is not Agile then - fine. Very rarely a buget is allocated for the Team (Time), that is believed to work in such a complex environment that is paid just to find a way through.
If the budget is allocated, then the only way to adjust is to change the scope (feature-set). So, Business has no guarantee that certain feature-set will be completed within the budget. (Because, indeed feature-set hadn’t been defined)
I dare to say, we’ve been wrong.
In next articles You will read about: