Benefit and Cost Periodized – Stretching Your Points –

W you estimate lifecycle cost and benefit of your software product, your stakeholders should be assured not only that you’ll deliver value but should also be informed when that value is expected to manifest itself. To do this you’ll need tools to lay out your estimates in time, so that you can plan and monitor your project’s investments and returns. After reading this, you’ll be able to take your points-based estimates for both cost and benefit (story points and benefit points) and distribute them out in time according to the best of your project’s knowledge. You’ll also be able to project cost and return according to most likely, bad case and good case uncertainty assessments.

In an earlier article in IEEE Software [7], we presented the core practice of assigning benefit points to epics (high-level requirements as user stories perceived at the project's early stages). That practice involves assessing epics' relative contribution to explicit project objectives in the project's business case; see Fig. 1(a) for an example where eight epics (E1-E8) are assigned benefit points toward three objectives (Obj1-Obj3).
Project objectives are expected to contribute to returns in the business' strategic plan, but may do so unevenly. So to reflect that objectives represent different business value, objectives are assessed for their contribution to strategic returns; three in the example (Ret1-Ret3) in Fig. 1(b). The fact that objectives do represent different business value is reflected by redistributing the assigned benefit points accordingly as seen in Fig. 1(c). There are several ways to redistribute, and you can see how this was done for this example in [7].
Assigning story points for life-cycle cost is another core practice that you probably are somewhat familiar with already-for this example assume the story points in Fig. 1(d). Now, we get a points-based benefit/costratio size by dividing benefit points by story points as shown in Fig. 1(c). This benefit/cost-ratio size can subsequently be used to order your backlog for producing high business value to cost early and to monitor and manage production with respect to realized potential business value and incurred cost. This was discussed earlier in a second IEEE Software article [8].
In those discussions, however, we considered cost and benefit as timeless quantities. But in fact, cost will be spent and benefit will be earned not in one go, but over time. Further, the rate of earning and expenditure will most likely vary over time, and during development there will be mostly expenditures and little earning. To understand and control the project's influence on the business' investments and earnings, it's important to sequence out both cost estimates and benefit estimates in time. This is called periodization. We will periodize our points-based estimates.
The time frame of the benefit and cost estimates we've considered up till now needs to be clarified. Since both cost and benefit estimates now include post deployment, which may have larger and more variable time spans than development, we must be explicit about what period of time we're providing estimates for. Time frame will most likely be explicit in the business case; say, if the business case is founded in a strategic period and that period's planned return. You might want to consult the Agile fractal figure in [7]. For example, the business case might specify that the system developed by the project should yield its estimated returns by the end of 4 years from project start. If that's the case, you should consider how the estimates are distributed along time in the given time frame (of say, 4 years).

Periodization
It's common to assess the progress of a project at regular intervals, and Finance is often interested in annual, biannual, tertiary or quarterly updates. Since we're agile and plan to release quite often, let's assume that we'd like to plan and assess the project at quarterly intervals. For our 4-year example, this makes 16 periods, and we'll illustrate by periodizing our estimates in Fig. 1 into these 16 periods.
Rather than redoing all your estimates in 16-fold, we suggest you use the estimates you already have and distribute them over the 16 periods. For this, we recommend using predefined periodization profiles. Fig. 2 gives you an idea for benefit. The general shapes of the benefit realization profiles in Fig. 2 are grounded in theories of learning and skill building [6]. For example, new tasks (e.g., using the functionality of a new IT system) usually take time to learn, and skill acquisition on such tasks may plateau after a while; as expressed in the profile "delay with plateau". Other tasks may inspire quick learning with or without an ensuing lack of enthusiasm for performing the task ("beginners enthusiasm and deterioration" and "immediate effect with linear increase and plateau"). If you don't have any insight in how benefit will be distributed in time, you can use the "uniform" profile.  As Applicant I can secure my identity in the application process by using MyID module to authenticate myself in order to ....

E2:
As Applicant I can start with a prefilled application form by using AutoFill module to retrieve and autofill all available and relevant information in order to ....

E3:
As Case Processor I can find all relevant information for a case by using CrossSearch module to retrieve applicant information from all relevant and permissible data sources in a single search in order to ....

E4:
As Division Manager I can manage productivity in my division by using QCon module to view statistics to monitor time and quality of case processing in order to .... E5: ... For cost, you can use profiles as those suggested in Fig. 3. We assume here that construction finishes within one period, since periods coincide with releases, but you can adapt your own cost periodization for development as you wish. For example, the "High development ( Immediate effect with linear increase and plateau

Fig. 2. Benefit realization profiles
expresses the expectation that development will be intense and that post-deployment costs will be much less and decrease over time, while "Low development (1 period) with increasing post deployment" expresses an expectation that a short-resourced development period results in greater post-deployment cost. If you don't have an inkling as to how cost will be distributed over periods, you could use the "one-period development with uniform post deployment" profile.

Periodization of points
You can see some of the profiles applied to the story and benefit points of Epic E3 in the upper table in Table 1.
The story points are distributed using the "High development (1 period) with low decreasing post deployment" profile. The benefit points toward Objective Obj1 are distributed using the "Beginner's enthusiasm and deterioration" profile, benefit points toward Obj2 are distributed using the "Uniform with delay" profile, and benefit points toward Obj3 are distributed using "Immediate effect with linear increase and plateau". The sum column is the total amount of E3's points periodized in the 16 periods (four years). In our example, we assume estimates were given initially for a four-year time frame. In this example, it's therefore estimated that it'll take exactly 16 periods for the total amount of an High development (1 period) with low decreasing post deplyoment

Fig. 3. Cost periodization profiles
epic's points to be spent or realized. Since construction in this example is planned for one period, benefit starts realizing one period after development starts, leaving one period less for realization, giving a sum less than the maximum possible for 16 periods (rightmost column, which corresponds to the points for E3 in Figure 1). This doesn't mean that the project will not deliver the total estimated benefit, it only means that it will not do so within 4 years, which happens to be the time frame the sponsor has imposed on the project; say for control purposes. So unless the system is shut down, both cost and benefit will continue to develop beyond the time frame of 4 years or 16 periods. Table 1 shows points templates that can be instantiated with monetary values for benefit points and story points. The blue bottom line computes the net points for each period, i.e., the benefit points minus the story points. When the table is instantiated with monetary values you get the net return. Note that the blue figures don't give meaning until you instantiate the benefit points and story points with monetary values. So these are the numbers that might appear in your spreadsheet prior to instantiating it.

Present value of future cash
When investing cash, it's important to take into account that future cash is not as much worth as present cash. This is because cash that you get in the future cannot be invested as it could if you had that cash now. Indeed, present value considerations highlight the importance of  incremental development over big bang delivery [3]. The second table in Figure 1 shows the same periodization ofE3, but takes into account the present value of future cash. Each period depreciates cash by 0.25%, assuming the potential for investing present cash at 1% per annum. The blue bottom line then represents the net present value (NPV) in points that might appear in your spreadsheet prior to instantiating it.

ACTIVITY: PERIODIZING PLANNED RETURN
Returning to the sponsor and project owner in the project initiation phase, they need to plan when money needs to be invested and when they can expect to get a return. In other words, the budget needs to be expressed along a time line. Using our benefit points and story points this is easily done. Assume that deployment has been planned in three increments with the intention of maximizing benefit over cost early as follows: Release 1: E3, E7, E2. Release 2: E4, E8, E1. Release 3: E5, E6. The sponsor would like to have a plan that is periodized in quarterly intervals, and needs to see this plan in a 4-year perspective for financial reasons. The cost and benefit profiles are applied based on the stakeholders' knowledge and experience.
Assume further that development takes one period. Table 2 shows the story point and benefit point estimates for the eight epics of our example periodized over 16 periods, according to the three releases, with 0.25% depreciation per period. The table is a template in points. We'll instantiate it with monetary values in a moment.
You'll notice how later releases leave less time for both spending and realization benefit, and clearly, shortening the time frame for realizing benefit is likely to have a greater impact. But this does not mean that incremental development denies full realization. With non-incremental development, you wouldn't be able to deploy anything until period 4, leaving less time for realization. With non-incremental development, the sponsor in general won't be able to demand as short a time span for evaluating a project's results.
Since Table 2 is a template in points, you can instantiate it by various monetary values for story points and benefit points to show the initial plan. First, Table 3 shows the template in Table 2 instantiated with 0.31 million per benefit point and 0.78 million per story point. This corresponds to p50 estimates for benefit points and story points. A so-called pX estimate is the value for which you estimate that there is a X/100 probability of an actual outcome being less or equal to the value. You can read how to compute pX estimates from threepoint uncertainty assessments for our example in [9], where we used Monte Carlo simulation to compute pX estimates. The Monte Carlo simulations resulted in p50 project outcomes for cost and benefit of 49.25 million and 65.5 million, respectively, and if you divide these numbers by the number of points, you get 0.31 million per benefit point and 0.78 million per story point. Table 4 gives you our ordered epics with p50 monetary values.
From Table 3, you can see in detail what the project's initial estimates imply for each epic's earnings over time, and you can anticipate when the project as a whole breaks even (between period 12 and 13) according to the p50 estimates (bottom "net discounted cash accumulated" line and blue curve). You can see what investments are needed (25.43 mill. over three periods) and the expected Return on Investment (ROI) which is net discounted cash divided by investment (6.34/25.43 = 0.25).
If you instantiate the "total discounted SP" and "total discounted BP' rows at the bottom of Table 2 with other monetary values generated from Monte Carlo simulations, you can compare expected outcomes at various levels of probability. Fig. 4

TABLE 2
Backlog at project initiation ordered initial release plan with story points and benefit points periodized over 16 periods (4 periods per year). Net present value discounted at 0.25% per period (1% per year).      Fig. 4 (a) shows periodized discounted benefit estimates according to p15 (0.29 million per benefit point), p50 (0.31 million per benefit point) and p65 (0.32 million per benefit point), as well as the initial benefit estimate (0.36 million per benefit point) prior to uncertainty analysis. By looking at how these lines move and where they cross each other, one can predict expenditure and earnings, and when the project breaks even according to various levels of certainty. For example, in a good case scenario (benefit p65 and cost p35), break even is period 11, while in a bad case scenario (benefit p15 and cost p85), the project doesn't quite break even within the 16 periods. Notice how the initial estimates without uncertainty analysis predicts break even at around seven periods. In this example, those initial estimates are not likely if one takes into account the uncertainty assessments that underlie the Monte Carlo simulations in [9].
The project owner can now lay out the project's financial boundaries in time by observing how the "total  Benefit/Cost net discounted points" line (blue) in Table 2 computes when instantiating the "total discounted SP" and "total discounted BP" rows . Fig. 4 (b) shows the corresponding curves for net discounted cash estimates according to p50, good case (benefit p65 and cost p35) and bad case (benefit p15 and cost p85) estimates. The project owner can plan finances according to theses boundaries and ask that project management aims at p50 or the good case estimate and insist that notice be made and steps taken whenever the project strays toward or outside the boundaries.

ACTIVITY: PERIODIZING PROJECTED RETURN
When the project gets underway, you can monitor its progress relative to the project's budget and boundaries of financial tolerance that you set up above. As an example, consider a detailing of the epics of Release 1 into stories as shown in Table 5, where stories inherit portions of their epic's story points and benefit points.
Here, it's evident that E7C gives low benefit to cost and is wasteful, so we eliminate it from the backlog. For the vacated capacity in Release 1, we elaborate E4 originally planned for Release 2, and find that E4A, E4D give best value for money and fit the vacated space. The remaining E4B, E4C give questionable benefit to cost, and we eliminate them too. Epics E6 and E5 are questionable as a whole (Table 4  and Table 5). When looking at the prognosis in Table 2, E6 generates value during three periods and nets out solidly negative. One might decommission E6 after the three periods, but that still wouldn't give value over cost. The periodization also renders E1 seemingly wasteful. We're choosing, however, to eliminate waste at the level of stories-not epics, because we'll assume in this example that there might be viable stories even in epics that are low on benefit/cost overall. So, E6, E5 and E1 are left in until elaboration time.
Just as the points template in Table 2 shows the discounted periodized backlog at project initiation, the points template in Table 6 shows the discounted periodized revised backlog at production time for Release 1 with waste eliminated. Again, you can instantiate Table 6 with different monetary values.
The brown curves in Fig. 5 show the resulting net discounted cash estimates for Release 1, according to p50, good case (benefit p65 and cost p35) and bad case (benefit p15 and cost p85) estimates. The blue curves are the project boundaries from Fig. 4 (b). You can see that the steps we took when planning Release 1 pay off relative to the project boundaries. For example, the brown projected p50 curve is above the blue planned good case curve, and that the break even point according to p50 is now around period 10 instead of around period 12. (The revised backlog has fewer story points and benefit points. The brown curves are based on recomputed Monte Carlo pX estimates on this revised backlog which gives slightly different pX values than the ones for the full backlog.)

PROJECT EXPERIENCE
A key point to agile is project learning, which pertains to a range of management aspects -motivational and social to get a feel for how to best run the complex system that a project is, as well as aspects of development and stakeholder experience. For our discussion, we're interested in how you express project experience in adjusting the monetary value of benefit points and story points.
After Release 1 is completed, you'll have actual values for how much a story point costs in that release. When refining and adjusting the backlog for Release 2, you should use that information. You can instantiate story points with the actual cost directly, or you can use the actual cost as the basis for a new Monte Carlo simulation to get adjusted pX estimates. If you want to be more advanced, you can use Bayesian statistics to integrate your present information (actual cost) with your past beliefs (previous estimated monetary value for story points).
By the time you've completed Release 2, stakeholders may have had time to gain experience with the part of the system deployed after Release 1. They may have opinions as to both benefit and post deployment cost that you should incorporate into the monetary values that you instantiate your points model with.
As your project gains more experience, you can update your monetary values for benefit points and story points and, perhaps, uncertainty will decrease; i.e., some of your three-point estimates can be narrowed [5]. When running fresh Monte Carlo simulations you can monitor  Backlog at start of Release 1 ordered into release plan with story points and benefit points periodized over 16 periods (4 periods per year). Net present value discounted at 0.25% per period (1% per year).  your project according to fresh information to the best of the project's knowledge at any point of time.
O ver a series of four articles, we've used the simple concept of assigning both benefit points and story points in various project management activities. On this points-based platform you can build powerful tools such as those of Earned Business Value Management [8], pointsbased uncertainty assessment [9] and the benefit and cost periodization in this article. You can also adapt a range of other models that we have not covered; e.g., [10], [1], [2] to this platform. You can instantiate all these pointsbased models with various monetary values; for example pX estimates.
In our running example, we ordered the backlog according to the basic benefit/cost ratio. But in fact, periodization impacts the optimal sequence of production. This article iintegrates our points-based approach with Denne and Cleland-Huang's Incremental Funding Method [4], [3], which you may consult to find out how to order your points-based backlog even better in light of periodization.
You can build models for different views. For example, the Earned Business Value Management regime gives you a dashboard with indicators of project progress in terms of your base estimates with no concern of exactly when and in what direction cash flows. It gives you metrics for the amount of estimated business value and functionality you're producing. The periodized regime, however, gives you a dashboard with indicators of when investment is needed and when return is expected. These two dashboards represent opposing interests belonging to those who favour product on the one hand versus those who favour return on the other hand. Difference in opinion regarding these views have likely resulted in many conflicts and may ultimately run projects aground. The good news is that you can now construct these dashboards using the same points-based data; data that all stakeholders to the project have produced and own jointly. This at least, means that decisions can be made closer to what amounts to a common vision of product and process.