Differences

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

--- how_do_i_convert_points_and_velocity_to_dollars [2016/10/03 10:45] – [[[Why Not Just Track Hours Like We Traditionally Do]]?] hpsamios
+++ how_do_i_convert_points_and_velocity_to_dollars [2016/10/03 10:49] – [Benefits of Using This Approach] hpsamios
@@ Line 42: / Line 42: @@
   * 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}}
-So what are the problems associated with using tracking hours? Some of the problems are:
-  * With agile we only plan to 5 or 6 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 (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. For more information on this see [[why_do_we_use_story_points_instead_of_hours|Why Do We Use Story Points Instead of Hours or Days?]]
-  * 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?"
-See [[can_we_trust_story_points_as_a_measure_of_effort|Can We Trust Story Points as a Measure of Effort?]] for additional thinking here.
 {{tag>Team Estimates Dollars Cost FAQ Points}}