3 ms·

This is where the right answer is "you do you", since only you and your team know what works best in your operating environment. The previous poster is correct

This is where the right answer is "you do you", since only you and your team know what works best in your operating environment. The previous poster is correct, though, that working backward from business value measurements in order to drive IC behavior is almost always the smartest path.

t-writescode 6y ago
Given this, I don't believe the this person's original argument is, to use their words, meaningful, then. > Velocity isn't a productivity metric, so your findings probably aren't meaningful. They were responding to someone that was using their average story point completion rate to track their productivity. This person seems to be talking about what sorts of work to work on - the kind that makes the company money. If it's already been predicted or measured that a certain project is going to earn the company money, then you need to know how long it's going to take to complete that project, which means either estimating it as a whole, or breaking the project into parts and estimating each part. Assuming two projects of similar mathematical proportionality of size and value, you can then estimate velocity based on how much projected time it's going to take to complete each step of each project, as estimated by story points or similar. In this way, story points can still be a meaningful metric that you can estimate velocity on. In short, the discussion is on two separate things and their initial premise of velocity being meaningless is not correct.
- jdlshore 6y ago
  There's a difference between productivity and prediction. Velocity is a great prediction tool. Given a total estimate, it can tell you approximately how many weeks it will take to be done. It's a unit conversion factor: velocity = 25 points / week, therefore 100 points = 4 weeks. Productivity is defined as output / input. Effort and time are both "input." Velocity is a way of converting from points (effort) to weeks (time). To measure productivity, you still need to define "output." OP said, "On the productivity question, if you're interested in some soft (very squishy) numbers, I can provide them." But OP didn't define "output," so they weren't measuring productivity. They just showed that their effort --> time unit conversion factor had changed. Given that there's any number of possible reasons for this—changes in hours worked, changes in overhead, changes in estimating technique, changes in estimate accuracy—the numbers probably aren't meaningful.
  - t-writescode 6y ago
    This still seems ancillary, though. They're measuring how much work they're getting done based around approximate predicted complexity / work amount using story points and then using that to map overall work output and charting it from between non-WFH and WFH. If the projects they're working on have tended to remain of similar complexity with people that tend to be consistent, then this seems like a perfectly fine metric for exactly what they're trying to discuss: the relative output from WFH and non-WFH.
    - jdlshore 6y ago
      Yes, that’s fair. I would say that hadn’t measured a change in productivity, but rather a change in overhead, but that’s probably just me being nitpicky about the word “productivity.”

t-writescode 6y ago

Given this, I don't believe the this person's original argument is, to use their words, meaningful, then. > Velocity isn't a productivity metric, so your findings probably aren't meaningful. They were responding to someone that was using their average story point completion rate to track their productivity. This person seems to be talking about what sorts of work to work on - the kind that makes the company money. If it's already been predicted or measured that a certain project is going to earn the company money, then you need to know how long it's going to take to complete that project, which means either estimating it as a whole, or breaking the project into parts and estimating each part. Assuming two projects of similar mathematical proportionality of size and value, you can then estimate velocity based on how much projected time it's going to take to complete each step of each project, as estimated by story points or similar. In this way, story points can still be a meaningful metric that you can estimate velocity on. In short, the discussion is on two separate things and their initial premise of velocity being meaningless is not correct.

jdlshore 6y ago
There's a difference between productivity and prediction. Velocity is a great prediction tool. Given a total estimate, it can tell you approximately how many weeks it will take to be done. It's a unit conversion factor: velocity = 25 points / week, therefore 100 points = 4 weeks. Productivity is defined as output / input. Effort and time are both "input." Velocity is a way of converting from points (effort) to weeks (time). To measure productivity, you still need to define "output." OP said, "On the productivity question, if you're interested in some soft (very squishy) numbers, I can provide them." But OP didn't define "output," so they weren't measuring productivity. They just showed that their effort --> time unit conversion factor had changed. Given that there's any number of possible reasons for this—changes in hours worked, changes in overhead, changes in estimating technique, changes in estimate accuracy—the numbers probably aren't meaningful.
- t-writescode 6y ago
  This still seems ancillary, though. They're measuring how much work they're getting done based around approximate predicted complexity / work amount using story points and then using that to map overall work output and charting it from between non-WFH and WFH. If the projects they're working on have tended to remain of similar complexity with people that tend to be consistent, then this seems like a perfectly fine metric for exactly what they're trying to discuss: the relative output from WFH and non-WFH.
  - jdlshore 6y ago
    Yes, that’s fair. I would say that hadn’t measured a change in productivity, but rather a change in overhead, but that’s probably just me being nitpicky about the word “productivity.”