Differences

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

--- how_do_i_convert_points_and_velocity_to_dollars [2016/09/27 14:45] – [Benefits of Using This Approach] hpsamios
+++ how_do_i_convert_points_and_velocity_to_dollars [2020/06/10 12:44] (current) – ↷ Links adapted because of a move operation hans
@@ Line 1: / Line 1: @@
 ====== How Do I Convert Points and Velocity to Dollars? ======
-Or "How do I figure out how much I've spent on something?"
+> Or "How do I figure out how much I've spent on something?"
+> Or "Do we still need to track time in a time tracking system for progress reporting?"
-Or "Do we still need to track time in a time tracking system for progress reporting?"
-====== Premise ======
 One base idea with agile to focus on completion of work rather than the effort it takes to get the work done. So, for example, we track the remaining work on a story rather than the counting the number of hours we spent on a story. This makes sense because while the effort might be interesting, we are really interested in the value delivered. Even if we now have the effort, it is history, so there is nothing we can do to change what happened.
@@ Line 20: / Line 16: @@
 In other words we determine the cost by proportioning the work associated with the thing we are interested in (here epic_or_feature) over the burdened cost of the team.
+The burdened cost of a Team allows us to factor in things like different labor rates in the different countries if that is important to the organization.
 ====== Benefits of Using This Approach ======
@@ Line 32: / Line 30: @@
   * Does not require additional reporting (“oh the UI is so simple everyone can do it” is just another road bump for people who should be focusing on producing value)
-In reality, if the work is large enough you’ll find an close enough approximation by simply counting the number of user stories in an epic as you do the work and proportioning the cost of the team that way (law of large numbers takes over - see [[blog:do_we_need_points_to_generate_a_release_burn-up_chart|Do We Need Points To Generate a Release Burn-up Chart?]] for more on this thinking). In the same way I expect you’ll eventually find that if you do to proportioning of cost via hours, you end up with pretty close to the same result as points. Many argue that ratios of points produce a better result than hours since it is more complete and both the people doing the work and the managers of that work talk about the same thing.
+In reality, if the work is large enough you’ll find an close enough approximation by simply counting the number of user stories in an epic as you do the work and proportioning the cost of the team that way (law of large numbers takes over - see [[do_we_need_points_to_generate_a_release_burn-up_chart|Do We Need Points To Generate a Release Burn-up Chart?]] for more on this thinking). In the same way I expect you’ll eventually find that if you do to proportioning of cost via hours, you end up with pretty close to the same result as points. Many argue that ratios of points produce a better result than hours since it is more complete and both the people doing the work and the managers of that work talk about the same thing.
 You can also come up with a "cost / point" calculation based on team velocity and cost (eg For a quarter, divide the total cost of the team by the total points completed by the team, (including Product Owner, Scrum Master, team members and the appropriate percentage of part-time contributor salaries). You now have the “cost per point”). Some will find this useful for looking ahead when estimates are required for projects, for example.
@@ Line 42: / Line 40: @@
   * Easily come up with ranges that represent future probability. For example you could say "if I do this work at my minimum velocity which represents a 90% probability that I will get it done, then the cost / date will be X while if I do this work at my average velocity which represents a 50% probability that I will get it done, then the cost / date will be Y". Plans can then be evaluated based on these probabilities.
-====== Why Not Just Track Hours Like We Traditionally Do ======
+{{page>why_not_just_track_hours_like_we_traditionally_do&noindent}}
+{{tag>Team Estimates Dollars Cost FAQ Points}}
-So what are the problems associated with using tracking hours? Some of the problems are:
-  * We only record 5 or 8 hours a day (or some other amount depending on what people end up doing). We could ask teams to record “everything” but that is an overhead (sub-tasks for everything like doing email). This is the purview of a “time tracking” system. We could just multiple all numbers by 8/5 to get to something more real, but is this any better than using points which we already have.
-  * Today I get people asking questions like “well I worked 7 hours on this thing, but we only planned for 5, what do I put in?” My answer has been “you put in how much work you have remaining …”. I expect this is because people still think they want to track time they spent on something, for whatever reason.If we start tracking time we are going to have to reconcile all the “ideal time” discussions with the “real time” happenings and come up with recommendations for these.
-  * One reason we work in points and velocity is that it is faster to produce estimates (bigger or smaller than something we know about) and provides better data (more accurate based on self-leveling of velocity information) than hour based estimates. Some argue that "people convert points to hours anyway - a 2 means 8 hours in our case". But if this is the case then you are not using points as it doesn't factor in complexity and risk into the discussion, and there is a fair chance you are spending a lot of time doing estimation. If you are going to do this anyway, you might as well get rid of the abstraction of points and just do everything in terms of (ideal) hours anyway.
-  * To me easier approach for cost is to determine burdened rate of team and use sum of completed versus sum of total for each epic to come up with a cost each team who has worked an epic. After all, we really only care about commitment and completion.
-But my biggest issue is the impact of putting this type of system in place from a cultural perspective. People say to me “you know, when we first started Scrum it was great because we could focus on getting the work done. Now we have slowly reintroduced all the bureaucracy we used to have back into the system so our ability to work has decreased.” My view is that this is a natural tendency of organizations – to introduce more and more cruft rather than trying to keep things simple. I think we need to be very careful about putting systems and bureaucracy in place.
-Worse than this, time recording takes people out of the mode of producing value and, in the worst cases, forces people to focus on creative ways to make time reports look real (or more accurately, good). It is sometimes too easy to focus on the question of how much something costs to produce, when the question we really should be driving is "how do we increase the production of value?"
-{{tag>Team Estimates Dollars Cost FAQ Points}}
-~~LINKBACK~~
-~~DISCUSSION~~