3 ms·

> If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes. You could do this, but it would b

by twic 4y ago

> If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes. You could do this, but it would be extremely silly. > This is bad math! Since the only purpose of velocity is to know roughly how many stories to prioritize in the backlog, none of this matters in the slightest.

seadan83 4y ago
> Since the only purpose of velocity is to know roughly how many stories to prioritize in the backlog, none of this matters in the slightest. Given error bars are not taken into account, the proposition is that velocity is incredibly inaccurate. Presumably, most of a backlog is prioritized (otherwise a high priority story could be at the bottom, leading to priority inversion). I thought the purpose of velocity was to know commitment size for a given sprint (how many stories to bring into a sprint). Given that the inaccuracy of velocity is not taken into account, nor the compounding of the uncertainty, knowing how much to commit based on an inaccurate value leads to a lot of "failed sprints". Re: prioritization, how you evaluate priority is completely up to a team. Anecdotally, Maesk ran agile and did not take into "cost of not completing a story". By that measure, there were three stories that were worth over 100x all other stories combined. Yet, they delayed deployment and efforts of these stories in order to "fit" in other stories that had low effort. Logically, with that large of a benefit, they should have stopped literally everything else and gone all in on those 3 stories. If you're really interested, I can try to dig up the youtube talk that went into this anecdote. The speaker in that video also noted that the data they looked at suggested the benefit of stories usually was magnitudes more than the level of effort. Hence, at times it almost does not matter the level of effort since the return is a better proxy for overall value.
- seadan83 4y ago
  I'd like to state this more succinctly. Prioritisation can be whatever you want, scrum does not say what 'priority' means. That can be as silly, or as complex as you want. There are many inputs to priority. In practice there seems to be an over-emphasis (near-obsession) over 'cost' rather than value provided. A good example of this are items that have deadlines to them. At some point, the "cost" of implementation is not the biggest factor, yet it often gets the most attention and time allocated (vs say, dollar cost of not implementing per day) My point with velocity is that it is inaccurate and using it will be just wild guessing. It's like saying, it's 65 degrees out - "cool, I'll wear a t-shirt". But, it's 65 degrees out plus or minus 30 degrees. As an engineer/scientist, we should already know that any number should always have error bars reported, otherwise it is meaningless. Similar to the temperature, you can look outside and infer the temperature through other means. It is likely then that "velocity" is noise compared to the true means we use to know if we have enough in the near backlog or not. Worse yet, velocity is often used as a cudgel to force overtime and declare a sprint "failed," even though velocity is so uncertain (yet is not treated as an uncertain value).

by twic 4y ago

seadan83 4y ago

> Since the only purpose of velocity is to know roughly how many stories to prioritize in the backlog, none of this matters in the slightest. Given error bars are not taken into account, the proposition is that velocity is incredibly inaccurate. Presumably, most of a backlog is prioritized (otherwise a high priority story could be at the bottom, leading to priority inversion). I thought the purpose of velocity was to know commitment size for a given sprint (how many stories to bring into a sprint). Given that the inaccuracy of velocity is not taken into account, nor the compounding of the uncertainty, knowing how much to commit based on an inaccurate value leads to a lot of "failed sprints". Re: prioritization, how you evaluate priority is completely up to a team. Anecdotally, Maesk ran agile and did not take into "cost of not completing a story". By that measure, there were three stories that were worth over 100x all other stories combined. Yet, they delayed deployment and efforts of these stories in order to "fit" in other stories that had low effort. Logically, with that large of a benefit, they should have stopped literally everything else and gone all in on those 3 stories. If you're really interested, I can try to dig up the youtube talk that went into this anecdote. The speaker in that video also noted that the data they looked at suggested the benefit of stories usually was magnitudes more than the level of effort. Hence, at times it almost does not matter the level of effort since the return is a better proxy for overall value.

seadan83 4y ago
I'd like to state this more succinctly. Prioritisation can be whatever you want, scrum does not say what 'priority' means. That can be as silly, or as complex as you want. There are many inputs to priority. In practice there seems to be an over-emphasis (near-obsession) over 'cost' rather than value provided. A good example of this are items that have deadlines to them. At some point, the "cost" of implementation is not the biggest factor, yet it often gets the most attention and time allocated (vs say, dollar cost of not implementing per day) My point with velocity is that it is inaccurate and using it will be just wild guessing. It's like saying, it's 65 degrees out - "cool, I'll wear a t-shirt". But, it's 65 degrees out plus or minus 30 degrees. As an engineer/scientist, we should already know that any number should always have error bars reported, otherwise it is meaningless. Similar to the temperature, you can look outside and infer the temperature through other means. It is likely then that "velocity" is noise compared to the true means we use to know if we have enough in the near backlog or not. Worse yet, velocity is often used as a cudgel to force overtime and declare a sprint "failed," even though velocity is so uncertain (yet is not treated as an uncertain value).