Metrics and measurement are important in software development projects. They are needed for planning, budgeting, organizing and controlling the work. They are 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 (Story POint Cost) as a metric to measure and track the cost of user stories and consequently the cost of Agile projects. I have developed the SPOC metric during my different interventions as an Agile/Scrum consultant. The metric has been used in several projects during the last three years. The main objectives of the SPOC metric are the following:
Provide the 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 of continuous improvement.
Keeping a history of the costs will allow more accurate budget estimates for future projects (Estimation based on teams experience).
SPOC (Story POint Cost) metric
SPOC stands for Story POint Cost. It represents the number of Man Days (Actuals) needed 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).
1.1) Sprint SPOC
Sprint SPOC is measured at the end of the Sprint. It’s the result of dividing the total man days consumed during the sprint by the velocity of the team (i.e. total size of the stories accepted during the sprint review).
Figure below shows an example of sprint SPOC for the first four sprints of a real life project on which I have worked. The project consists of Implementing a financial application.
1.2) Intermediate SPOC
Intermediate SPOC represents the average cost of one story point after n sprints. It’s the result of dividing the cumulated man days consumed during the different sprints by the total size accepted.
Table below shows an example of intermediate SPOCs for the financial application project.
2.2 Release SPOC
Release SPOC is measured at the end of the release (i.e. last sprint). It’s the result of dividing the cumulated man days consumed during the different sprints by the total size accepted.
In our example the release SPOC is 6,25 M/D. This is also the average SPOC after Sprint 10 (last sprint).
Graphical representation of the SPOC metric
Figure above is a graphical representation of SPOC evolution at the three levels (Sprint, Intermediate, Release).
Figure 1 : SPOC graphical representation
Case study
This section presents a case study that illustrates the usage of the SPOC metric in one of my clients..
The context
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 from 2013 to 2014 (financial applications for internal and external use).
There were several scrum teams working on the same project (between 2 and 5 teams). Average team size is 8 persons (including Scrum Masters).
SPOC history
The graphic below shows the history of SPOC at release level.
The SPOC for project 1 was around 7,57 M/D. This is the first real life project managed using an Agile approach (A small pilot project has been done before). The duration was 10 Sprints of 3 weeks with 2 teams of 8 persons each.
Figure 1 : SPOC history (Release level)
2.1 Analysis of SPOC after project 1
This SPOC of Project 1 was too high. A retrospective involving the participating teams have identified the following reasons:
The teams were new to Scrum.
Some stories have been underestimated.
The first sprints where technical with no visible added value to the users; the teams tried to make the whole architectural work at the beginning. Due to some changes in the scope of the release, some architectural rework was necessary which has reduced the velocity of the teams.
There was some coordination overhead due to the presence of 2 teams working on the project. The repartition of work between the two teams was not optimal (many dependencies) between the teams.
2.2 Corrective actions
The challenge was to improve the SPOC in the next projects. Based on the lessons learnt, some corrective actions have been identified:
Minimize dependencies between the teams. This has been achieved by a better split and repartition of user stories on 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 successful. The SPOC went down to 4,22 M/D in project 2. In project 3, the SPOC reached then to 3,66 M/D (The teams have not been changed).
Conclusion
In this article we presented “SPOC” as a metric to measure the cost of story points in Agile/Scrum projects. The metric can have different usages:
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
The metric is simple to use. Corrective actions depend on the context. Scrum teams can identify the most relevant actions depending on their context.
Aucun commentaire:
Enregistrer un commentaire