Plan Costs
Agile uses a top-down approach to Cost Management with the starting point being the business case.
Cost is measured based on the work rate of the team and the time required to complete the project work by assessing the effort required for each work activity. Long term planning is not undertaken, instead, a short term view is assessed based on the recent project performance.
The focus on cost planning is the team's efforts. However, this is schedule dependent in terms of the time required to deliver the product. Cost and schedule are generally quantified using the team's velocity which in essence measures the pace of completing a product increment.
A guiding principle for agile managers is that the total cost is dependent on the value delivered. However, this is constrained by investment funds outlined in the business plan.
Effectively, agile is focused on minimizing the development and production cost to recoup the investment. In terms of feature delivery, early development is not necessarily beneficial from a cost perspective as it does not account for changes that may be required at a later phase in the project.
Whilst the cost is primarily measured based on the team's throughput, it is important to measure this based on the fully burdened labour cost. This considers a total cost inclusive of additional items such as the cost of equipment used, office space, etc.
Estimate Costs and Determine Budget
Considered as an approximate calculation for prediction of the amount number quantity per the extent of something, the estimation of cost in an agile environment necessitates a more united and co-operative approach. It is one of the crucial activities that gains paramount importance in programs using agile practices.
The cost estimation of programs is necessitated and carried throughout the entire acquisition phases ranging from the trade-off analysis like AOA business cycle analysis, economic analysis as well as life cycle cost estimates (Agile Cost Estimation | AiDA, 2020). However, one of the basic principles of obtaining agile cost estimates is to focus on the outcomes rather than an activity and to ensure the successful completion and delivery of the project. Also, the estimation assists with involving everyone associated with the project as well as the decisions of whether the project should be implemented.
For complying with the process of estimation, there are numerous techniques in use for the agile project cost estimation. Some techniques such as analogy, parametric, engineering build-up as well as extrapolation from actual cost estimates. However, the actual method used for the process is grossly dependent on the level of maturity and the availability of real-time data as well as the life cycle stage of the project. In the case of agile projects, the cost estimates have a higher degree of uncertainty in the earlier levels than in the later period because of the maturity and materialization of risks.
The process of estimation requires the consideration of elements of the number of requirements, in the user story level, evaluation of the complexities of each and the velocity units of throughput per unit of time to cater to individual or unified principles of risk reduction through diversification as well as setting up of a safe limit through benchmarking (Goodpasture, 2010).
To get an estimate the agile approach relies on expert opinion, analogy, and disaggregation.
Expert opinion relies on experience, opinion, knowledge, and gut feeling.
Analogy is based on the comparison of the story being estimated to one or more other stories.
Disaggregation is dividing a story or feature into smaller parts making it easier to estimate.
According to Aida, (2010), The biggest cost driver when estimating is product size. Story points can be the relative measure of size when estimating agile developments. The amount of effort involved in developing the feature, its relative complexity, and the inherent risks are estimated in story points where a small simple story could be assigned lower points and more complex could get higher points.
Planning poker is an effective way for combining these three techniques.
Mike, (2005) describes the planning poker technique as “each estimator is given a deck of cards with a valid estimate shown on each. A feature is discussed and each estimator selects the card that represents his or her estimate. All cards are shown at the same time. The estimates are discussed and the process repeated until agreement on the estimate is reached.”
Affinity grouping is another team-based estimation technique. The first item at hand is read out to the team, the same with the second item. It is then determined among the group which item is larger or smaller than the first item. Then the third item is described at which point it is determined amongst the team if that is larger or smaller than the first/second item and so on (Sliger, 2012).
There are also some tried and tested models/algorithms that are used to estimate costs and determine budgets in Agile projects. COCOMO II is an example of this. It consists of three sub-models, which have varying degrees of accuracy depending on how far you are in the project. It looks at the various drivers that impact projects and uses 5 scalability drivers and 17 cost drivers in its model and weights them appropriately (Ismael, Jamil 2007). The figure below shows an example of the cost drivers and weighting that can be applied.
Control Costs
Most projects are undertaken to either save or make money. One of the characteristics of Agile is to eliminate waste where possible. Some believe that simple actions such as lengthy meetings, or excessive documentation are a form of waste, taking up valuable developer time which could be more productively spent working on and developing the actual product.
Lean thinking, developed by Poppendieck & Poppendieck (2014), is a mindset, and similar to Scrum has its own values, which includes eliminating such waste wherever possible (thus saving on project schedule and cost). One technique Poppendieck & Poppendieck recommend in order to identify and eliminate waste is to create a Value Stream Map. By identifying the smallest unit possible in a project, a minimal marketable feature (MMF), and drawing boxes around each step involved to deliver the product from its inception, one can see where delays and cost may build-up, whilst the process and work for this product lays idle and still.
Figure 10 shows a Value Stream Map for a project in a traditional waterfall project. In this instance, it took 71 days from start to finish. But in reality, only 35.5 days were actually spent working on and developing the product. Whilst the delays might have been genuine and unavoidable (waiting for feedback, waiting for supplies), it shows how cost and delays can escalate if allowed to get out of control.
An example of value streams in action via Agile using Scaled Agile Framework (SAFe) can be seen in Figure 11 below. This ensures a focus on value-driven outcomes whilst eliminating nonvalue add activity through clear identification of the steps and people involved in the delivery of value.
There are two value streams identified Operational and Development Value Streams:
Another tool, as outlined by Vanzant-Stern (2020) is to use the TIM MODEL. Vanzant-Sterns outlines the following,
“Lean tools focus on reducing waste, which, by default, will reduce cost. A company with effective cost-reduction activities in place will be better positioned to adapt to shifting economic conditions. The most helpful thing from Lean in this area is the TIM WOODS model. This is also known as the eight areas of waste”.
By examining any of these areas, it should allow a PM to identify if waste in that area exists, and if it can be eliminated.
