6 ms·

When Agile jumped the shark

20 points by ljw1001 14y ago

ljw1001 14y ago
Not totally different, but simpler, which counts. Earned value presupposes things like someone put a value on individual deliverables and that there's a budget that matters. Neither happens much in commercial software in my experience. Since most software cost is headcount * time * cost-per-person, tracking time is a pretty good proxy for that. Of course no metric matters if you produce bad code and call it progress.
jacques_chester 14y ago
It used to be that you had Earned-Value Management and the concomitant EV Charts. One could take the first derivative of the current point on the chart (or perhaps do something fancier involving moving weighted averages) and use that to predict[1] how the EV chart would play out in future. But EV charts and first derivatives are old fashioned and hokey. Practically waterfall! Instead we use the latest in agile management: burndown charts and velocity. Totally different. [1]: Though see every software project ever for an example of why linear extrapolation is a hilariously foolish way to settle on a firm estimate.
DanielBMarkham 14y ago
This was a bit meandering, but I feel his pain. I was very skeptical at first, but I've become a big fan of story points: they decouple estimation from scheduling, and that's a good thing. Note that they are not "... a new, fuzzy unit of measure..." likewise they are also not a "...metrics sleight-of-hand..." This a very simple, yet powerful exercise. Relatively size the things you have to do. Now, without caring about what the points are, select what you can do in the next time-frame. Measure your ability to deliver against this. Over time, your relative estimates get better and your ability to commit gets better. The kicker is that none of this has a damn thing to do with scheduling. Once you can tell reliably tell me you're going to deliver 10% of the remaining total work in the next two weeks, I know for a fact you have 18 more weeks left in the project. Then I can then release plan and work dependencies based on real-world data and without breathing down a developer's neck. Meeting schedules doesn't have to be (and shouldn't be) the higher-stress thing many of us make it out to be. The author seems to not be able to get scheduling out of his head. If you're constantly wondering how many days a story point is, don't use story points. You don't understand them. Note that for such a simple idea, there are several gotchas here. Most teams screw up story points and velocity. Anybody have the PM that divides the points by the sprints remaining and then announces what the velocity will be? Or how about the ScrumMaster that empirically determines current velocity and then tells the team how many stories they can do for the upcoming sprint? Ouch. Lots of bad practices out there. That doesn't make story points bad, though. Just makes most people suck at them. (Shameless plug: I have a book on being a ScrumMaster and an upcoming one on backlogs. http://tiny-giant-books.com/scrummaster.htm http://tiny-giant-books.com/scrummaster.htm )
- ljw1001 14y ago
  If they're not fuzzy, how big is a point?
  - DanielBMarkham 14y ago
    It's not fuzzy. It's unit-less. The number has no size or meaning outside the list of other sizes representing the work for that particular team for that particular sprint. It doesn't transport between teams, it doesn't mean the same thing from sprint to sprint, and it doesn't represent any qualities of the underlying system. You're asking for the definition of something that's just a relative number. It's like asking how long a piece of string is. That sounds whacked, so let me try again. What I'm doing when I take a list of future system behaviors and ask a team to relatively them is creating the parameters to a model that doesn't exist yet. The process of creating, revising, and implementing the model is what the team does each sprint. That's why initial estimates are so whacked (and they should be). Yes, for your particular team on your particular project maybe you get to the end and say "Hey, on average a story point amounted to 1.5 days" But I have no earthly idea why anybody would do that or care about that translation. It would a _very bad thing to do_. You only know the "answer" once you're done. And the answer is empirically determined by application of the model; it's not a guess. Remember the old quadratic equation? ax^2+bx+c=0? Story points are like knowing "b". So how big is "b"? See? Makes no sense. It's just part of a parameter used to do other things. "Size" has no meaning here.
    - jacques_chester 14y ago
      > It's not fuzzy. It's unit-less. Except that somebody will come along and just use it as a proxy for some unit they care about. And that will probably be time. Tada! You're right back where you started. Counting things out in magic beans doesn't make the problem go away. Humans are pretty good at this exchange-rate business. You might as well estimate in domain-specific terms that you can later actually verify and calibrate. Such as SLOCs, function points, object points, modules + tests and so on.
      - 14y ago
T-hawk 14y ago
Story points vs time estimates is not an either-or question. You can use both. My team at my job does. We do time estimating for each two-week sprint (Scrum) so we know what will fit, and have fuzzier point estimates in the backlog for longer-term planning by the product owners. Both levels of abstraction are appropriate in the right context. To DanielBMarkham in a sibling comment: > Or how about the ScrumMaster that empirically determines current velocity and then tells the team how many stories they can do for the upcoming sprint? That's what we have, but is that bad? Isn't that how the points should be used to gauge predicted velocity? Of course it shouldn't be treated as a concrete inviolate set-in-stone prediction, but that methodology comes in pretty accurate for estimating.
bradly 14y ago
My big problem with estimating in story points is that it ignores the reality that how long something takes is directly tied to who is doing the work. A junior eng, a senior eng, someone who just started, someone who isn't familiar with that piece of the system, the person who wrote and has always maintained that piece of the system. These people will all do a given task in a different amount of time. Possibly an order of magnitude differently when comparing a junior eng not familiar with the code to the codes author. This is okay. Embrace it. Plan for it.
- amurmann 14y ago
  I would argue that this is actually an advantage of story points. You don't know who will be working on it at estimation time. But a 2-pointer should take any developer about twice as long as it would take the same developer to do a 1-pointer. If you have many super fast, very senior developers you get more points done and have a higher velocity. That's where the speed will be reflected and you can see how much your team can get doen in one iteration. This allows you to plan your iteration without having to care who works on any given story.
- ljw1001 14y ago
  On a sufficiently large project (more than a few people) the differences in productivity average out, as do to some extent estimation errors. I never expect any individual estimate to be correct; it's more important to get an accurate estimate of how far off your estimates are in aggregate.

20 points by ljw1001 14y ago

Not totally different, but simpler, which counts. Earned value presupposes things like someone put a value on individual deliverables and that there's a budget that matters. Neither happens much in commercial software in my experience. Since most software cost is headcount * time * cost-per-person, tracking time is a pretty good proxy for that. Of course no metric matters if you produce bad code and call it progress.

jacques_chester 14y ago

It used to be that you had Earned-Value Management and the concomitant EV Charts. One could take the first derivative of the current point on the chart (or perhaps do something fancier involving moving weighted averages) and use that to predict[1] how the EV chart would play out in future. But EV charts and first derivatives are old fashioned and hokey. Practically waterfall! Instead we use the latest in agile management: burndown charts and velocity. Totally different. [1]: Though see every software project ever for an example of why linear extrapolation is a hilariously foolish way to settle on a firm estimate.

DanielBMarkham 14y ago

This was a bit meandering, but I feel his pain. I was very skeptical at first, but I've become a big fan of story points: they decouple estimation from scheduling, and that's a good thing. Note that they are not "... a new, fuzzy unit of measure..." likewise they are also not a "...metrics sleight-of-hand..." This a very simple, yet powerful exercise. Relatively size the things you have to do. Now, without caring about what the points are, select what you can do in the next time-frame. Measure your ability to deliver against this. Over time, your relative estimates get better and your ability to commit gets better. The kicker is that none of this has a damn thing to do with scheduling. Once you can tell reliably tell me you're going to deliver 10% of the remaining total work in the next two weeks, I know for a fact you have 18 more weeks left in the project. Then I can then release plan and work dependencies based on real-world data and without breathing down a developer's neck. Meeting schedules doesn't have to be (and shouldn't be) the higher-stress thing many of us make it out to be. The author seems to not be able to get scheduling out of his head. If you're constantly wondering how many days a story point is, don't use story points. You don't understand them. Note that for such a simple idea, there are several gotchas here. Most teams screw up story points and velocity. Anybody have the PM that divides the points by the sprints remaining and then announces what the velocity will be? Or how about the ScrumMaster that empirically determines current velocity and then tells the team how many stories they can do for the upcoming sprint? Ouch. Lots of bad practices out there. That doesn't make story points bad, though. Just makes most people suck at them. (Shameless plug: I have a book on being a ScrumMaster and an upcoming one on backlogs. http://tiny-giant-books.com/scrummaster.htm http://tiny-giant-books.com/scrummaster.htm )

ljw1001 14y ago
If they're not fuzzy, how big is a point?
- DanielBMarkham 14y ago
  It's not fuzzy. It's unit-less. The number has no size or meaning outside the list of other sizes representing the work for that particular team for that particular sprint. It doesn't transport between teams, it doesn't mean the same thing from sprint to sprint, and it doesn't represent any qualities of the underlying system. You're asking for the definition of something that's just a relative number. It's like asking how long a piece of string is. That sounds whacked, so let me try again. What I'm doing when I take a list of future system behaviors and ask a team to relatively them is creating the parameters to a model that doesn't exist yet. The process of creating, revising, and implementing the model is what the team does each sprint. That's why initial estimates are so whacked (and they should be). Yes, for your particular team on your particular project maybe you get to the end and say "Hey, on average a story point amounted to 1.5 days" But I have no earthly idea why anybody would do that or care about that translation. It would a _very bad thing to do_. You only know the "answer" once you're done. And the answer is empirically determined by application of the model; it's not a guess. Remember the old quadratic equation? ax^2+bx+c=0? Story points are like knowing "b". So how big is "b"? See? Makes no sense. It's just part of a parameter used to do other things. "Size" has no meaning here.
  - jacques_chester 14y ago
    > It's not fuzzy. It's unit-less. Except that somebody will come along and just use it as a proxy for some unit they care about. And that will probably be time. Tada! You're right back where you started. Counting things out in magic beans doesn't make the problem go away. Humans are pretty good at this exchange-rate business. You might as well estimate in domain-specific terms that you can later actually verify and calibrate. Such as SLOCs, function points, object points, modules + tests and so on.
    - 14y ago

T-hawk 14y ago

Story points vs time estimates is not an either-or question. You can use both. My team at my job does. We do time estimating for each two-week sprint (Scrum) so we know what will fit, and have fuzzier point estimates in the backlog for longer-term planning by the product owners. Both levels of abstraction are appropriate in the right context. To DanielBMarkham in a sibling comment: > Or how about the ScrumMaster that empirically determines current velocity and then tells the team how many stories they can do for the upcoming sprint? That's what we have, but is that bad? Isn't that how the points should be used to gauge predicted velocity? Of course it shouldn't be treated as a concrete inviolate set-in-stone prediction, but that methodology comes in pretty accurate for estimating.

bradly 14y ago

My big problem with estimating in story points is that it ignores the reality that how long something takes is directly tied to who is doing the work. A junior eng, a senior eng, someone who just started, someone who isn't familiar with that piece of the system, the person who wrote and has always maintained that piece of the system. These people will all do a given task in a different amount of time. Possibly an order of magnitude differently when comparing a junior eng not familiar with the code to the codes author. This is okay. Embrace it. Plan for it.

amurmann 14y ago
I would argue that this is actually an advantage of story points. You don't know who will be working on it at estimation time. But a 2-pointer should take any developer about twice as long as it would take the same developer to do a 1-pointer. If you have many super fast, very senior developers you get more points done and have a higher velocity. That's where the speed will be reflected and you can see how much your team can get doen in one iteration. This allows you to plan your iteration without having to care who works on any given story.
ljw1001 14y ago
On a sufficiently large project (more than a few people) the differences in productivity average out, as do to some extent estimation errors. I never expect any individual estimate to be correct; it's more important to get an accurate estimate of how far off your estimates are in aggregate.