Comments on: Agile Practices Overview: Points and Team Velocity http://enfranchisedmind.com/blog/posts/agile-points/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Brett http://enfranchisedmind.com/blog/posts/agile-points/#comment-38009 Brett Thu, 16 Dec 2010 21:46:09 +0000 http://enfranchisedmind.com/blog/?p=1123#comment-38009 I thought the way it worked, or the way it works where I work, is there is a bucket of points available to burn in a two week iteration. This is not to say that 30 points = 2 weeks, therefore 1 week = 15 points and 1 day = 3 points. Doesn't work like that. There are 30 points. There is a 2 week iteration. Then, projects are estimated in terms of points burn. When we reach 30 we say the iteration has been planned. The projects then need to be executed within the iteration. Its not about calculating points in terms of time. Its about getting a bunch of work done in a duration of time. Its a little more abstract but not entirely abstract. I don't see how points estimation can work outside of the context of the larger Agile development methodology, specifically iteration planning. The two are intimately tied together. The concept of points estimation breaks outside of Agile methodology. I thought the way it worked, or the way it works where I work, is there is a bucket of points available to burn in a two week iteration. This is not to say that 30 points = 2 weeks, therefore 1 week = 15 points and 1 day = 3 points. Doesn’t work like that. There are 30 points. There is a 2 week iteration. Then, projects are estimated in terms of points burn. When we reach 30 we say the iteration has been planned. The projects then need to be executed within the iteration. Its not about calculating points in terms of time. Its about getting a bunch of work done in a duration of time. Its a little more abstract but not entirely abstract. I don’t see how points estimation can work outside of the context of the larger Agile development methodology, specifically iteration planning. The two are intimately tied together. The concept of points estimation breaks outside of Agile methodology.

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/agile-points/#comment-37926 Robert Fischer Mon, 06 Dec 2010 19:34:32 +0000 http://enfranchisedmind.com/blog/?p=1123#comment-37926 You're absolutely right. I'm very much in agreement with you. The term "24 hours" seems to have a meaning because we feign a consensus on what "hour" means. And, in that sense, a point has no meaning, because it has not fixed term. What a "point" has is a contextual meaning and an inferred meaning. The team develops a sense of a point, although the number of points that the team may get done in a week may well vary: by virtue that this previous task was 3 points, this new task should be 3 or 5 points. This is how language works, and human beings are really good at normalizing this kind of language. What I'm talking about with velocity is tracking that difference, not only from developer to developer but over time—after all, Mark Hours Before His Baby Was Born aren't the same as Mark Hours After His Baby Was Born. And instead of assuming I'm on top of tracking all that or placing myself in the position of estimating how people's life is changing, we can use empirical measurements based on information we've received about the process. Which is exactly what I'm proposing. As for when things are going to get done: it's actually no more work for the project manager. The process you're describing is easily done on a spreadsheet. Compare that to your option, where you're allocating tasks to the various developers, having the task estimates change depending on who is picking them up, and basically creating an NP-complete bin packing problem for yourself. That's a real nightmare for ETA! You’re absolutely right. I’m very much in agreement with you.

The term “24 hours” seems to have a meaning because we feign a consensus on what “hour” means. And, in that sense, a point has no meaning, because it has not fixed term.

What a “point” has is a contextual meaning and an inferred meaning. The team develops a sense of a point, although the number of points that the team may get done in a week may well vary: by virtue that this previous task was 3 points, this new task should be 3 or 5 points. This is how language works, and human beings are really good at normalizing this kind of language.

What I’m talking about with velocity is tracking that difference, not only from developer to developer but over time—after all, Mark Hours Before His Baby Was Born aren’t the same as Mark Hours After His Baby Was Born. And instead of assuming I’m on top of tracking all that or placing myself in the position of estimating how people’s life is changing, we can use empirical measurements based on information we’ve received about the process. Which is exactly what I’m proposing.

As for when things are going to get done: it’s actually no more work for the project manager. The process you’re describing is easily done on a spreadsheet. Compare that to your option, where you’re allocating tasks to the various developers, having the task estimates change depending on who is picking them up, and basically creating an NP-complete bin packing problem for yourself. That’s a real nightmare for ETA!

]]> By: Mark http://enfranchisedmind.com/blog/posts/agile-points/#comment-37925 Mark Mon, 06 Dec 2010 18:20:25 +0000 http://enfranchisedmind.com/blog/?p=1123#comment-37925 Actually, rather that make the system more abstract, I would make it more concrete by creating units of time for each developer. Having written software for over 30 years now its been my experience that one programmer can easily be 20 to 30 times more effective than another. (The latency in management realizing this fact is another matter.) What I would like to see is "Mark Hours" vs "Bob Hours". If I estimate the work in "Mark Hours" and then Bob comes in to do the task the actuals will, as they always do, vary wildly. They problem then becomes one of knowing your team and knowing who's going to do what way up front when your bidding the job. What needs to be re-thought is the concept that all programmers are created equal. They aren't. Not by a long shot. Actually, rather that make the system more abstract, I would make it more concrete by creating units of time for each developer. Having written software for over 30 years now its been my experience that one programmer can easily be 20 to 30 times more effective than another. (The latency in management realizing this fact is another matter.) What I would like to see is “Mark Hours” vs “Bob Hours”. If I estimate the work in “Mark Hours” and then Bob comes in to do the task the actuals will, as they always do, vary wildly. They problem then becomes one of knowing your team and knowing who’s going to do what way up front when your bidding the job.

What needs to be re-thought is the concept that all programmers are created equal. They aren’t. Not by a long shot.

]]> By: Mark http://enfranchisedmind.com/blog/posts/agile-points/#comment-37924 Mark Mon, 06 Dec 2010 18:06:32 +0000 http://enfranchisedmind.com/blog/?p=1123#comment-37924 "has meaning" as in "it takes the Earth 24 hours to rotate around its axis". How many "points" is this? More importantly, when can my project manager expect his solution when I tell him "Oh, that's a 60 pointer for sure". He's going to take that "60 point" estimate, look at the historical velocity and convert it to real time. He'll also convert the uncertainty in my estimate by looking at my historical estimates vs. actual points achieved. Why are we making all this work for the poor guy/gal. Just tell him how long you think its going to take and save abstractions for your code. “has meaning” as in “it takes the Earth 24 hours to rotate around its axis”. How many “points” is this?

More importantly, when can my project manager expect his solution when I tell him “Oh, that’s a 60 pointer for sure”. He’s going to take that “60 point” estimate, look at the historical velocity and convert it to real time. He’ll also convert the uncertainty in my estimate by looking at my historical estimates vs. actual points achieved. Why are we making all this work for the poor guy/gal. Just tell him how long you think its going to take and save abstractions for your code.

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/agile-points/#comment-37914 Robert Fischer Tue, 16 Nov 2010 00:00:52 +0000 http://enfranchisedmind.com/blog/?p=1123#comment-37914 Define "has meaning". This approach has been experimentally demonstrated to contain and communicate information—namely, it effectively communicates the amount of work that the team is accomplishing by its own measurement. That's something that has happened in reality, so I'm not sure how that fails to "have meaning". You are absolutely right to say that "six points", for instance, communicates no meaningful information without its context. But no language works without context, so that doesn't bother me too much. You need to catch the postmodernism train, Mark—the reality is that the entire concept of "absolute" is pretty much out the window as soon as you're dealing with people, so the very basis of your critique falls out. This is doubly true in the workplace, where illusions like "one hour of work" as a metric does such incredible damage to teams. Define “has meaning”. This approach has been experimentally demonstrated to contain and communicate information—namely, it effectively communicates the amount of work that the team is accomplishing by its own measurement. That’s something that has happened in reality, so I’m not sure how that fails to “have meaning”.

You are absolutely right to say that “six points”, for instance, communicates no meaningful information without its context. But no language works without context, so that doesn’t bother me too much.

You need to catch the postmodernism train, Mark—the reality is that the entire concept of “absolute” is pretty much out the window as soon as you’re dealing with people, so the very basis of your critique falls out. This is doubly true in the workplace, where illusions like “one hour of work” as a metric does such incredible damage to teams.

]]>