Employees involved in IT-development within the scope of an agile transformation often ask themselves, how to balance the budget or offer of an internal as well as customer project with the outcome, which is often unclear at the beginning of the cooperation.
Because one thing is for sure: any project initially needs an offer in order to be awarded. Without it, decision makers cannot budget the work. This offer needs to determine the rough outline, i.e. the broad goals and effect of the application. It is otherwise impossible to produce a cost indication, without which no client will ever award a project.
Developers therefore need to work out, how they can produce a cost indication with the least effort, all the while leaving enough scope of action to react to new insights during the product development.
The rule of thumb here is, that a team should spend no more than 1 sprint (e.g. 2 weeks) to work out the initial requirements. A well coordinated team can do this in a matter of a day or two thanks to their experience and the respective domain knowledge. The most important goals and resulting requirements should thereafter have been defined in workshops, documented and estimated in relation to each other. With those estimations and the team strength, the time (in sprints) needed for the implementation can be estimated and an appraisal made for the contractor. According to our experience such relative estimates show a divergence of 20% in comparison with previous estimation methods but are much cheaper to generate.
It is very important to point out to the client, that these estimates are based on the current state of knowledge and can change with new insights thanks to the iterative process. They are not a hard commitment. A decision on whether or not the goals have already been reached and where to invest further into the achievement of objectives is made together with the client, through the iterative process and the transparent progress-control after each sprint.
