Javascript is currently disabled. This site requires Javascript to function correctly. Please enable Javascript in your browser!

Project performance  > Agile Estimating and Agile EVM

Agile estimating

In agile development, User Stories (US) are used to capture the customer's functional requirements and their sum defines the product to be developed. The size of US is based on the relative complexity of each User Story and is expressed by a measure called Story Points (SP).

The User Stories are prioritized based on several factors; the most important among them their business value and relative complexity. They are then broken down into “Work Items” that are grouped together and developed in an iteration called “Sprint”. It should be mentioned that a User Story may be implemented into more than one Sprint. The efforts of each Work Item are estimated with a technique based on Delphi methods (Planning Poker) in order to plan the efforts of a Sprint. The estimation of the size (Story Points) and the estimation of the effort (Planning Poker) are thus done separately. After the first Sprints are completed, the team has to estimate its Velocity, i.e. the number of points it can achieve in one Sprint. This Velocity is regularly re-evaluated. By linking the Velocity and the number of points to be developed (Product Backlog), the agile team can estimate the number of Sprints required to complete the project. They can then get an idea of the end date of the project/release.

our approach

Our solution for agile project estimating is based on the measurement of the functional size. The method is standardized, based on customer requirements and allows the organization to assess and monitor the performance of its projects on a comparable basis. It is relatively easy to use and can be applied at different levels: Product, Release and Iteration/Sprint. The method is flexible and can be adapted to the reality of each organization. And, what is important, the proposed method respects the fundamental philosophy of agile development and estimating.

We can help you to develop and implement projects estimation practices based on either the agile "standard" approach (Story Points, Planning Poker, Velocity, etc.) either on our own approach. Indeed, the approach RSM Techno takes all the good practices of agile estimating, but with a standardized measure. This will allow you to estimate the size of Release (project), of each User Story and of each iteration (Sprint) and to compare these estimates between different teams and different projects. The estimating process is supported by a tool and requires no additional effort on the part of estimator.

 

Limitations of agile estimating

The agile methods have developed their own estimation and progress monitoring metrics that seem to work well and which are, according to the practitioners, very useful for agile teams. However, the portrait is different if we analyze these metrics from the perspective of the organization’s needs.

Indeed, there are no methods for estimating and monitoring the performance of agile projects based on a standardized procedure. This makes it very difficult, if not impossible, to measure and compare the development productivity between projects within an organization and between projects of one organization and those of the industry.

Agile project and Earned Value Management (EVM)

When we talk about EVM and agile, there is more questions than answers. Can EVM apply to agile projects? If so, should EVM approach be adapted in order to respect the fundamentals of an agile method? What kind of metrics can be used to report on agile projects, waterfall or agile metrics?

EVM has traditionally been applied to traditional waterfall type development with the assumption that the project scope will remain constant during the development process. The agile method works in an opposite way: the time is fixed and the requirements (scope) are negotiable. Many agile proponents think that EVM is too rigid and not enough flexible to embrace agile projects. On the other hand, some EVM practitioners see agile as too disordered and unplanned and thus not respectful of good project management practices.

We believe that Agile and EVM can work together, but to do it, both sides have to challenge some of their principles. We have developed an approach that defines EVM metrics that can be used on agile projects and that can provide useful information to the management. Our approach respects the fundamentals of both methods; it preserves the advantages of Agile and, at the same time, it benefits from the rigor of the EVM concept. The proposed metrics repose on agile project data and their calculation is adapted to the agile project life-cycle and terminology. Agile terms and EVM measures are translated in order to find the relationship between them. The agile data are presented in reports and dashboards in a language that agile practitioners as well as business management can easily understand.

Is Agile EVM a Real EVM?

Considering EVM such as standardized by the ANSI Standard 745B, the answer is "No". But if we look at the basic EVM measures (the value of the work performed, the value of the work planned and the actual cost), they are not so different compared to the measures used in agile approach. They may have different names, they can be calculated in different ways, but basically, in both cases, they must answer the same questions: What we have planned to deliver? - What we have delivered? -How much we have spent?

So,if the approach can provide the right responses to the questions cited above, it doesn’t really matter what its name is: EVM, Agile EVM, Agile Metrics or something else. As the Chinese proverb says: "No matter if it is a white cat or a black cat; as long as it can catch mice, it is a good cat."
Asset 7