Metrics and measurement are important in software development projects. They're needed for planning, budgeting, organizing, and controlling the work. They're also necessary for continuous improvement.
Scrum provides three main metrics: velocity
, sprint burn-down
, and release burn-up
. These metrics focus mainly on the development team and on the product. They don't directly address the cost of the project.
In this article I present SPOC (S
ost) as a metric to measure and track the cost of user stories and consequently the cost of Agile projects. I've developed this metric during my work as an Agile/Scrum consultant with different clients (finance, industry, services). The metric has been used in several projects during the last three years. The main objectives of the SPOC metric are the following:
Providing Scrum teams (and managers) with a simple means for measuring and tracking the development cost all along the project.
Having a concrete measure of story point cost will reinforce team awareness about the budget. This allows the team to register cost reduction among its objectives for continuous improvement.
Keeping a history of the costs will allow for more accurate budget estimates for future projects (estimation based on accumulated experience of the teams).
SPOC (Story POint Cost) metric
SPOC stands for S
ost. It represents the number of man days (M/D) spent to realize one story point. The SPOC metric can be measured at three different levels:
SPOC at the sprint level: measured at the end of each sprint
Intermediate SPOC: the average cost after n sprints.
SPOC at release level: measured at the end of the release (last sprint)
Measuring the cost at different levels allows regular inspections at different moments in the project's life cycle and helps identify corrective actions when needed.
1. Sprint SPOC
Sprint SPOC is measured at the end of the sprint as follows:
The figure below shows an example of sprint SPOC for the first sprints of one of my projects. The project was about implementing a financial application.
2. Intermediate SPOC
Intermediate SPOC represents the average cost of one story point after n sprints. It's the result of the division of the accumulated man days consumed during the different sprints, by the total size realized (accepted stories).
The table below shows an example of intermediate SPOCs for the financial application project.
3. Release SPOC
Release SPOC is measured at the end of the release (i.e., the last sprint). It's the result of the division of accumulated man days consumed during the release, by the total size accepted.
In our example, the release SPOC is 6,25 M/D.
Graphical representation of the SPOC metric
This figure is a graphical representation of SPOC evolution at the three levels (sprint, intermediate, release).
This section presents a case study that illustrates the usage of the SPOC metric with one of my clients.
The client of the case study is a major player in the financial industry located in Paris, France.
The metric has been used on three sequential projects between 2013 and 2014 (financial applications for internal and external use).
There were several Scrum teams involved (between two and five teams of eight persons each, depending on the project).
The graphic below shows the history of SPOC at release level:
The SPOC of Project 1 was around 7,57 M/D. This was the first project managed using Scrum by the client (only a small pilot project had been done before). The duration was 10 sprints of 3 weeks. Two teams of 8 persons each worked on the project.
Analysis of SPOC after project 1
This SPOC of Project 1 was too high. A retrospective involving the participating teams has identified the following reasons:
The teams were not mature enough (were new to Scrum).
Some stories were underestimated.
Most of the work done during the first sprints was dedicated to the implementation of the whole architecture of the system. There were no functional features with added value to the client. This was an error. Due to some changes in the scope of the release, much architectural rework was necessary. This has considerably reduced the velocity of the teams.
There was some coordination overhead due to the presence of two teams working on the project. The repartition of work between the two teams was not optimal (there were many dependencies) between the teams.
The challenge was to improve the SPOC in the next projects. Based on the lessons learned, some corrective actions have been identified:
Minimize dependencies between the teams. This has been achieved by a better split and repartition of user stories among the teams.
Better coordination between the teams: regular Scrum of Scrum meetings; setup of common working group coping with shared aspects of the project (architecture, data model).
Better definition of sprint content. Functional stories with value for the client have been assigned to the teams since the first sprints. This helped the teams to do technical architectural work all along the release (a work has been done before starting to sprints on order to define the bases of the architecture).
The corrective actions above were a real success for the teams. The SPOC went down to 4,22 M/D in project 2. In project 3, the SPOC has been reduced to 3,66 M/D (the teams have not been changed).
In this article we proposed "SPOC" as a metric to measure the cost of story points in Agile/Scrum projects. The metric can have different uses:
Keeping track of story point costs, which allows the teams measuring their performances and identify improvement actions
Estimating the budget of future projects based on the experience of the teams
Any comments are welcome.