There is a reason why large corporations in particular shy away from Scrum. It is not that they don’t use Scrum – but often they do so with little conviction and more often than not if as driven out of necessity.
The accusation: Scrum projects are difficult to plan and certainly not suitable for fixed prices.
This is justified by the methodology itself, in which functional requirements are only roughly described as Stories or epics in the product backlog before the start of implementation and considerations about architecture and technology have often not yet taken place.
This makes it difficult to sell the methodology to management in large projects, which usually have to be provided with fixed budgets (internally) or offered at a fixed price (externally). The risks of miscalculation appear too high.
Nevertheless, there are an increasing number of projects that can no longer be pre-planned in the classic way, either because there is no time or because the complexity is too high; this includes extensive networking with other systems and the resulting dependencies that are difficult to assess.
Apparently this is a dilemma and reason enough to show a way how Scrum projects can be made fixed priced.
Offering a fixed price for a software development project is a big challenge in any case. It requires an exact knowledge of the functional requirements of the customer, the technologies to be used, the interfaces involved, the planned architecture, the skills of the own employees, the possibility of parallel development, etc.
As we will see later, well over a hundred factors have an influence on the actual development effort. This applies to every project no matter which methodology is used.
In addition, there is the above-mentioned Scrum handicap of the functional requirements that are only roughly described at the time of project planning.
At this point I would like to put an end to a misunderstanding that is unfortunately widespread if you have just stumbled over the term “project planning” in connection with Scrum.
Scrum is an implementation methodology, not a project management methodology. This means that Scrum works within a project and not instead of the project or as the project.
This should also answers the question if project managers and things such as project plans, review boards, jour fixe, etc. are still necessary in Scrum. Yes, they are, but they have to be tailored to the use of the Agile implementation methodology. This applies to both the project roles and the project management tools.
Get a fixed price in three easy steps
Let’s go back to the fixed price problem and a proposal how you can solve it – because that is perfectly feasible.
To accomplish this task, we recommend reducing the complexity first. We do this by taking a perspective typical of Scrum: A software is described through its features, not through its technology, architecture, layer or whatever.
We look at the functional scope separately from its implementation and try to find a measure for both.
In short, in order to determine a fixed price for a software project, we need three pieces of information in our approach:
- Scope (Story Points, Function Points or Agile Function Points)You need a measure for the scope, i.e. the functional size of the software to be developed.
- EffortA measure for the effort you need to make to implement functionality.
- CostsYour costs and prices
We can neglect the third point in our consideration, because you should be aware of your costs per ‘managed workplace’. If not, you would have a fundamental problem and would have to start all over again.
The first point represents the feature-oriented view typical for Scrum, while the second point deals with the more than one hundred factors mentioned above, which influence the actual development effort per functional unit.
Some of these are the technologies to be used, the basic architecture (e.g. client server or SOA), the skills of the developers, the communication with your customers, the use of nearshoring or offshoring, the type of company organization (e.g. matrix organization), your CI strategy, the number and availability of test systems and test data, the planned project duration, the number of developers, the project language and much more. Many of these factors are company-specific, others (those are also quite a few) are project-specific.
Fast or precise: ‘Story Points’ or ‘Function Points’
Usually, when developing software, Scrum describes the scope of functions in the form of features. A feature describes what needs to be developed, and not how it is implemented.
Of course, not all Stories will be written before the project starts. At best, only the first 1 to 3 Sprints are pre-planned. At an early stage the backlog consists mainly of features (SAFe) or epics (SCRUM).
However, these are rough functional descriptions that should describe the scope of at least the MVP (minimum viable product). If this is also not possible, the prices can be determined for at least one PI (Product Increment – a milestone lasting about 4 Sprints).
All features are combined in a product backlog. This means that the scope is complete, albeit only described roughly.
Now we have to find an objective measure for this range of functions, which can later be used as a factor in our equation.
Story Points
Scrum has a measure for this: Story Points. Generally, Story Points are introduced as a unit for the complexity of a Story. This makes it very problematic to determine a fixed price for the scope as defined in the product backlog.
In general, the theoretical use of Story Points is still reasonably plausible, but in practice it is controversial. Why?
First, Story Points do not represent an objective measure but are a purely subjective unit of measurement that merely indicates the relative degree of complexity (i.e. implementation effort) of a Story in relation to other Stories. And the dimension is defined by the team, which is why SAFe suggests so-called normalized storypoints.
In contrast to the public discussion about Story Points, I do not consider this to be problematic in itself, at least not if I can translate “subjectively” with “team and project-specific” and assume that the team also comes to this assessment.
The problem lies more in the unit itself, because it is a unit for the complexity of a Story. This changes the perspective, away from the functional size (scope) and towards the implementation effort. It also removes the separation between functional requirements and the effort of their implementation as suggested in Scrum.
As a result, the approach of reducing complexity as described above is abandoned immediately and the more than one hundred factors mentioned above must immediately be taken into account again when assessing the complexity of the Story.
However, this can only be done sufficiently during Sprint planning, when the team is intensively involved in estimating the Story. At the time of Sprint planning, however, we could use hours as a unit.
If Story Points are to be used for the fixed price determination, then they must be estimated much earlier. Usually this is done by an experienced architect who is then burdened with estimating both the functional size and the numerous other factors in one go.
I think it’s easy to understand why this exercise can be carried out quickly, but it provides only highly inaccurate estimates.
Function Points
There is another way of determining a suitable measure: Function Point Analysis. Story Points and Function Points are fundamentally different concepts.
In short, while Story Points are a subjective unit for the complexity of a Story, Function Points are an objective measure – i.e., independent of teams and projects – of the pure functional complexity of a project.
Size of a request. Functional requirements can be compared directly, regardless of whether they are completely new developments or are being implemented in an existing, historically grown and poorly documented application with far-reaching refactorings. We all know that between those two scenarios, in extreme cases, cost factors can be in the double-digit range.
Function points are largely an objective measure, since they are not estimated, but counted according to clear and simple rules. The restriction ‘as far as possible’ assumes that there is certainly room to maneuver when interpreting the counting rules. According to studies, these do not exceed 10 percent with experienced function point analysts. Counting Function Points, however, is more difficult. But the effort is worth it.
In one of my major projects (50 developers, development time of 3 years), counting about 8,000 Function Points took a function point analyst about 2 weeks. For a project worth 30 million Euros this is certainly acceptable.
Another advantage is that the function tree created during the count can be used directly for creating Stories, which later simplifies project controlling and scope management considerably. Nevertheless, we must certainly take it as a criticism that the Function Points have not exactly been accepted in the past 30 years. However, 30 years ago there was no Agile development and maybe they were simply way ahead of their time. It doesn’t matter if you choose Story Points or Function Points, i.e. if you work with a relative or absolute measure, this first reference value should be able to describe the scope.
Effort Estimation
Once you have determined the functional size of your project based on the individual functional requirements of your product backlog and the sum of the function or Story Points of the individual backlog items, you have already taken a big step forward.
All you need to do now is set a price for the implementation of a function or Story point and calculate the effort involved. In principle, there are two ways to do this. The first way is to simply create a proof-of-concept in a preliminary project by developing a small prototype and calculating the total costs.
This has two advantages.
First, you can verify your original Function or Story Point count using the result.
Second, you get real values for the effort if you can ensure that the proof-of-concept is indeed representative. However, this is often the problem, which means that such a proof-of-concept is not always possible.
The then obvious second way is to use an estimation method that takes into account all the influencing factors already mentioned several times above. COCOMO (Constructive Cost Model) estimation, for example, is an algorithmic cost model that provides exactly that.
The application is certainly not quite trivial, but the estimates are of high precision and significantly reduce the economic risks. You can present your fixed price to your customers and management with a clear conscience (because it is absolutely comprehensible).
Scope Changes
The procedure to describe the functional scope of your project with a measure such as the function or Story Points and then to determine a price for the implementation of a function or Story point has another decisive advantage which pays off especially in projects in which SCRUM is used.
You can offer your customers a blanket and abstract development of functionalities at a fixed price, even if these have not yet been defined.
Since you know how much the implementation of a functionality (Function-Points) costs, independent of the actual functional requirement, you can handle every Scope Change easily and transparently.
You agree with your customer that the price is valid for a certain number of Function Points or Story Points. If the customer goes beyond this number when designing the individual Stories during the project, i.e. if the scope is extended, the price increases automatically.
Of course, Function Points have advantages over Story Points. You should at least use the normalized version of Story Points, as suggested by SAFe, otherwise cross-team evaluations can become rather complicated.
In return, the customer is given the opportunity to prioritize active scope management and to fine-tune the functional scope for each Story.
Another advantage of using Function Points: Since the function point analysis is a neutral and objective count, you can also include an independent function point analyst who enjoys the trust of both parties, if desired.
Projects like these are usually much less stressful, because the customer can concentrate on the scope and the service provider only has to deal with the implementation, which is usually challenging enough.
