4 ms·

Of course the higher value a thing has, the less you need to quantify that it has high value. Conversely, the lower your margin, the more you need to control it

Of course the higher value a thing has, the less you need to quantify that it has high value. Conversely, the lower your margin, the more you need to control it to within an inch of its life. You could even say that if it needs estimating it maybe isn't worth doing.

jacques_chester 12y ago
Where I work we have weekly sessions to plan the week's work. We ask our customer to put stories in order of value to them. It might look like this: A B C D ---- week marker ---- Then we perform a quick estimate for each of the stories. We can talk them over quickly, ask clarifying questions and so on. Because of research on the unpacking effect, I like to make sure to say aloud the sort of subtasks I think will be involved, but sometimes we don't. We quickly do a "shoot out" and then simultaneously reveal our point estimates for the story we're estimating. On divergence we explain our reasoning. Sometimes it takes a few rounds to reach a consensus. So after this process, it might look like this: A 4 points ---- week marker ---- B 2 points C 1 point D 1 point Because we've got velocity of 4 points. At this point the customer can change the order of stories. They might decide that having stories B, C and D is actually better than having story A by itself. Just trading purely on value or on estimated effort/complexity doesn't give you the full picture. It's the ratio of the two per-story and between stories that helps a customer make the best-informed decision.
- dreamfactory2 12y ago
  Agree that you want to get a view on whether a task is easy or not - but this is rarely understood until you have started. And frankly most advocates of estimation aren't talking about T-shirt sizes but some kind of currency they can tot up to measure 'productivity'. The danger with trying to predict it is that you are getting deep into a specific implementation at that point and it is exerting a pull on the project aims. I think that can conflict with business value as the driver for doing anything. What's more important for eliminating waste (and death march ftm) is a set of alternatives (outcomes and implementations) and a framework which makes it cheap to back up and switch routes when you find something isn't turning out to be easy thing you imagined.
  - jacques_chester 12y ago
    We deliberately focus on simple estimates of a unitless measure (story points), rather than imposing a unit that will cause distortions in our thinking. The value of those points is specific per-project and it emerges from actually doing the project. I agree that allowing change is important. Reduce the cost and risk of changes, and you will make changes as and when required. You'll also become less preoccupied with perfect planning, because it won't be necessary to manage risk. There's two loops here. One leads to small, light, manoeuvrable projects. The other leads to building bigger plans because the risk is higher, which means that a bigger plan is needed, which raises the risk, so the plan is more detailed so that ...
    - dreamfactory2 12y ago
      Impact mapping gives you that big plan without having to detail implementation and keeps it manoeuvrable. Kanban lets you switch the backlog around through the day and doesn't lock the project into sprints (which are mini waterfalls imo). Estimation is entirely optional here. (The main benefit I've seen from estimation is in forcing a dev team to collectively confront what's involved in implementing a feature - as an input not an output.)
      - jacques_chester 12y ago
        I've found that Kanban leads to coordination overhead because you always have too much work in flight in too many stages. I prefer story-by-story development, which is the direction to which most Kanban implementations wind up evolving. One small thing, to completion, at a time, per pair.
        dreamfactory2 12y ago
        WIP limits should iron this out

jacques_chester 12y ago

Where I work we have weekly sessions to plan the week's work. We ask our customer to put stories in order of value to them. It might look like this: A B C D ---- week marker ---- Then we perform a quick estimate for each of the stories. We can talk them over quickly, ask clarifying questions and so on. Because of research on the unpacking effect, I like to make sure to say aloud the sort of subtasks I think will be involved, but sometimes we don't. We quickly do a "shoot out" and then simultaneously reveal our point estimates for the story we're estimating. On divergence we explain our reasoning. Sometimes it takes a few rounds to reach a consensus. So after this process, it might look like this: A 4 points ---- week marker ---- B 2 points C 1 point D 1 point Because we've got velocity of 4 points. At this point the customer can change the order of stories. They might decide that having stories B, C and D is actually better than having story A by itself. Just trading purely on value or on estimated effort/complexity doesn't give you the full picture. It's the ratio of the two per-story and between stories that helps a customer make the best-informed decision.

dreamfactory2 12y ago
Agree that you want to get a view on whether a task is easy or not - but this is rarely understood until you have started. And frankly most advocates of estimation aren't talking about T-shirt sizes but some kind of currency they can tot up to measure 'productivity'. The danger with trying to predict it is that you are getting deep into a specific implementation at that point and it is exerting a pull on the project aims. I think that can conflict with business value as the driver for doing anything. What's more important for eliminating waste (and death march ftm) is a set of alternatives (outcomes and implementations) and a framework which makes it cheap to back up and switch routes when you find something isn't turning out to be easy thing you imagined.
- jacques_chester 12y ago
  We deliberately focus on simple estimates of a unitless measure (story points), rather than imposing a unit that will cause distortions in our thinking. The value of those points is specific per-project and it emerges from actually doing the project. I agree that allowing change is important. Reduce the cost and risk of changes, and you will make changes as and when required. You'll also become less preoccupied with perfect planning, because it won't be necessary to manage risk. There's two loops here. One leads to small, light, manoeuvrable projects. The other leads to building bigger plans because the risk is higher, which means that a bigger plan is needed, which raises the risk, so the plan is more detailed so that ...
  - dreamfactory2 12y ago
    Impact mapping gives you that big plan without having to detail implementation and keeps it manoeuvrable. Kanban lets you switch the backlog around through the day and doesn't lock the project into sprints (which are mini waterfalls imo). Estimation is entirely optional here. (The main benefit I've seen from estimation is in forcing a dev team to collectively confront what's involved in implementing a feature - as an input not an output.)
    - jacques_chester 12y ago
      I've found that Kanban leads to coordination overhead because you always have too much work in flight in too many stages. I prefer story-by-story development, which is the direction to which most Kanban implementations wind up evolving. One small thing, to completion, at a time, per pair.
      - dreamfactory2 12y ago
        WIP limits should iron this out