3 ms·

> By keeping the backlog prioritized at all times You can't really do this without having some idea of how long each item in the backlog will take. If feature

by twic 4y ago

> By keeping the backlog prioritized at all times You can't really do this without having some idea of how long each item in the backlog will take. If feature A is twice as valuable is feature B, should A or B come first in the backlog? Depends if A takes the same time as B, or four times as long. (ignoring various other considerations about how you prioritise, and just focusing on delivering value here) This is why rough estimation is part of the planning process in XP. The developers estimate stories so that the product owner can prioritise them. The estimates don't need to be precise, just roughly right relative to each other, to act as a denominator. Since the developers are only pulling from the top of the backlog, the product owner doesn't need to prioritize the whole thing, just enough to keep the team busy. That means the developers only need to estimate stories which the product owner is considering for prioritization. You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. But that would involve everyone interrupting everyone else quite often. So typically, you get together once a week and do this until you have enough stories to keep the developers busy until the next get-together. You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity.

seadan83 4y ago
Sure you can keep your backlog prioritized at all times. Prioritization can be net benefit, or can be net ROI, the choice is yours! If you find out that item A will take half the time, perhaps that will boost its ROI and change its position in the queue. If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes. Nothing in this way of defining priority is really any different between scrum & kanban. Perhaps the only key difference is when work is allocated to be done, scrum often focuses on 'how long will it take' to avoid "assigning too much to one sprint". Hence, a low ROI item could certainly be fit into a sprint simply because of time constraints, even though it might be really low on the overall ROI list (thus a priority inversion where the wrong thing is worked on simply because it fits an arbitrary time period). > You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. If you have your backlog prioritized (or at least deep enough you can pull work for a while), then doing this continously is cake. The developer pulls from the top of the backlog. When a new task or a story is introduced, it is stack ranked. When and how often you introduce new stories in kanban is really up to you. So it need not be a constantly disruptive process. Typically new stories are looked at on a daily basis, which allows for a lot of responsiveness. At the same time, if knowledge changes about a story, it's priority rank is changed right then. It does not take very long to do stack ranking. > You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity. Tl;dr, velocity makes some interesting assumptions and uses bad math Velocity does not take into account error bars. This is bad math! Each story has an error bar of give or take 30% (assuming it is well estimated with Fibonnacci). EG: An '8' could be a 6.5, or could be a 10.5. Yet, somehow by adding up the expected size of stories together the overall accuracy increases.. This is an oddity and bad math. Velocity should always be reported with a plus or minus, yet, it doesn't.. Somehow all of math behind propogation of error is assumed to cancel out. Beyond bad math, velocity only says how well you did last sprint, and "past performance does not guarantee future results." In short, velocity assumes that people can estimate. The only tasks that will have reliable estimates are ones that are very similar to something you have already done many times (eg: how long would it take you to brush your teeth with this new electric toothbrush? You know how long it takes to brush teeth with a convention toothbrush, so your estimate would be pretty good). But let's say, how long will it take you to learn Electromagnetism? Cool, you just learned that, how long will it take you to learn Calculus III? If you've taken Calc I and II, you would perhaps have something of an idea, but you're still to be really way off on estimating that.
- 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

Sure you can keep your backlog prioritized at all times. Prioritization can be net benefit, or can be net ROI, the choice is yours! If you find out that item A will take half the time, perhaps that will boost its ROI and change its position in the queue. If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes. Nothing in this way of defining priority is really any different between scrum & kanban. Perhaps the only key difference is when work is allocated to be done, scrum often focuses on 'how long will it take' to avoid "assigning too much to one sprint". Hence, a low ROI item could certainly be fit into a sprint simply because of time constraints, even though it might be really low on the overall ROI list (thus a priority inversion where the wrong thing is worked on simply because it fits an arbitrary time period). > You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. If you have your backlog prioritized (or at least deep enough you can pull work for a while), then doing this continously is cake. The developer pulls from the top of the backlog. When a new task or a story is introduced, it is stack ranked. When and how often you introduce new stories in kanban is really up to you. So it need not be a constantly disruptive process. Typically new stories are looked at on a daily basis, which allows for a lot of responsiveness. At the same time, if knowledge changes about a story, it's priority rank is changed right then. It does not take very long to do stack ranking. > You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity. Tl;dr, velocity makes some interesting assumptions and uses bad math Velocity does not take into account error bars. This is bad math! Each story has an error bar of give or take 30% (assuming it is well estimated with Fibonnacci). EG: An '8' could be a 6.5, or could be a 10.5. Yet, somehow by adding up the expected size of stories together the overall accuracy increases.. This is an oddity and bad math. Velocity should always be reported with a plus or minus, yet, it doesn't.. Somehow all of math behind propogation of error is assumed to cancel out. Beyond bad math, velocity only says how well you did last sprint, and "past performance does not guarantee future results." In short, velocity assumes that people can estimate. The only tasks that will have reliable estimates are ones that are very similar to something you have already done many times (eg: how long would it take you to brush your teeth with this new electric toothbrush? You know how long it takes to brush teeth with a convention toothbrush, so your estimate would be pretty good). But let's say, how long will it take you to learn Electromagnetism? Cool, you just learned that, how long will it take you to learn Calculus III? If you've taken Calc I and II, you would perhaps have something of an idea, but you're still to be really way off on estimating that.

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).