Differences

This shows you the differences between two versions of the page.

--- how_do_we_do_software_capitalization_when_we_go_to_agile [2020/06/04 11:57] – Removed LINKBACK hans
+++ how_do_we_do_software_capitalization_when_we_go_to_agile [2020/10/08 06:19] (current) – Readability hans
@@ Line 21: / Line 21: @@
 document.
-====== Want to Know More? ======
+With these definitions in place we then:
-Perhaps the best description of the approach is by [[https://www.infoq.com/articles/agile-capitalization|Dan Greening - Why Agilists Should Care About Capitalization"]]. The approach and results described here exactly mirror my experiences (so I won't write it up again:-))
+  * Mark, label, tag, or otherwise attribute work to indicate whether something is "capitalizable" or not. This could be done at whatever level makes sense for you. If you have a strong relationship between Epics and Stories, and you feel the Epics are defined so they differentiate capitalized work for other work, then you might set things up so that the Epic tracks "capitalization", and just use assume that anything associated with that Epic can be used in the calculation for capitalization.
+  * Develop an understanding of the fully burdened cost of a Team or Team of Teams. This is calculated by summing up the fully burdened cost of a person each person on a Team. Usually organizations will use an overall average across all Teams to be the fully burdened coast of a Team to simply calculations. A typical calculation is:
-{{page>can_we_trust_story_points_as_a_measure_of_effort}}
+> Fully burdened cost of a person: $150K / year
+> Average number of people on a Team: 8
+> Fully burdened cost of a Team: 8 x $150K = $1200K / year
+  * Track the velocity of the Team for each Iteration or Sprint. If you are using Scrum you are probably doing this already. If you are using Kanban, you'd track Throughput per unit time (e.g. every two weeks). For the sake of an example, lets say:
+> Velocity of the Team for this Iteration: 50 points
+  * To calculate how much of the Iteration (or Sprint) can be capitalized, sum up the number of Story Points that associated with the "capitalization" tag, and that get delivered in that Iteration (or Sprint). Divide that sum by the Velocity of that Iteration (or Sprint) to get a ratio, then multiply that ratio by the fully burdened cost of a Team for an Iteration (or Sprint). If using Kanban, use a similar approach based on counts of tickets getting delivered over the calculation period. Continuing with the example:
+> Sum of Story Points delivered in this Iteration: 10 points
+> Percentage work in this iteration that can be capitalized: 10 / 50 = 20%
+> Dollar value of work that can be capitalized for this Iteration: 20% x $1200K / 26 (as $1200 is per year) = $6240
+NOTE: Knowing information like fully burdened cost of a Team is pretty good practice anyway. Iterations (or Sprints) mean we are spending money and so we should be asking ourselves whether we are making good investments; will we get return for the dollars we are spending.
+{{page>can_we_trust_story_points_as_a_measure_of_effort&firstseconly&noindent&notags&nouser&nomdate&nodate}}
+====== Want to Know More? ======
+  * Perhaps the best description of the approach is by [[https://www.infoq.com/articles/agile-capitalization|Dan Greening - Why Agilists Should Care About Capitalization"]]. The approach and results described here exactly mirror my experiences (so I won't write it up again:-))
+  * [[how_do_i_convert_points_and_velocity_to_dollars|How Do I Convert Points and Velocity to Dollars?]]
+  * [[our_estimates_are_terrible|Our Estimates are Terrible!]]
+  * [[what_can_we_do_to_improve_our_point_based_estimates|What Can We Do To Improve Our Point Based Estimates?]]
 {{tag>FAQ estimates forecast capitalization executive finance}}