views:

252

answers:

6

Reading the XP book, I have a condtradiction in my mind that I cant address and am wondering if you guys can help.

XP says write stories on index cards, assign those to a developer, have her estimate how long the task would take and then use pair programming to do the coding bit.

So then her and the developer she pairs with must choose to implement either his or her task. Based on that choice the work they perform is then counted toward the estimate that she made for the task. Is that estimate still valid, because it seems to be dependent on who she is working with?

+4  A: 

The estimates have to be made with the knowledge of who is going to do the tasks.

Otherwise they make no sense.

Developer: "I can drive from Toronto to Los Angeles in 17 hours" (that's two random cities in the world and a 110% made up number, don't sue me if it isn't even possible to drive between those two cities)

Manager: "Ok, then I'm going to give you this old rusty kids bike. See you in Los Angeles in 17 hours"

Obviously that's not going to work.

So the estimates have to be made after it has been decided who's going to work on the tasks.

If not, you're going to have to build one big homogenous team, consisting of clones or something, that will all take the same amount of time as every other team member on a particular task.

Note, this is kinda the same problem of one person estimating a task, and another going is going to implement it. Unless the two are extremely familiar with each other (or at least the person estimating knows the other person 100%), you're going to get incorrect estimates.

"I estimate Bob will use 2 hours on this"

Like that's ever going to fly.

Lasse V. Karlsen
Base on google map, Toronto to Los Angeles is 4,055 km – about 37 hours
Hapkido
Good to know, I'll leave my answer as it is though :)
Lasse V. Karlsen
Heterogeneous = Different, Homogeneous = the same
SoapBox
Ah, that's why it rang wrong in my ears, thanks, I'll fix that! My excuse is that english is not my primary language, and I'm sticking to that explanation! :) (and we'll just conveniently forget that the words are roughly the same in my primary language)
Lasse V. Karlsen
I agree that the estimates have to be made after it has been decided who's going to work on the tasks, but how do make that happen practically, when doing pair programming and rotating the pairs every couple of hours?
Nick
If you rotate the pairs every couple of hours, you're going to waste lots of time having each new person/pair trying to get to grips with the previous teams work before they can work at full speed, so any estimates you might have then would still be off.
Lasse V. Karlsen
+1  A: 

All developers in the team should be involved when estimating a story. The estimate shouldn't depend on who's going to do the work. That's not even known at estimation time. We use Planning Poker wich is both fun and gives good results.

PEZ
how do you come up with a single estimate which both the pair of graduate junior engineers and the pair of senior engineers can work to?
Graham Lee
I will have to agree with this one, based on typing speeds, amount of smoke breaks, research time, if a developer has done something similar or not, how well the developer knows the process, it's all relative to the developer and not generic at all.
Tom Anderson
I seriously disagree with this answer. There is no way you can estimate how long a task is going to take without knowing who is going to execute it. "Sure, it'll take 2 hours". "Ok, then we'll let the person we just hired do it, I'll be back in two hours to see the results".
Lasse V. Karlsen
Have you tried Planning Poker? In implementation you often pair experience with the novice. You don't estimate time, you estimate size, in points.
PEZ
A: 

So then her and the developer she pairs with must choose to implement either his or her task. Based on that choice the work they perform is then counted toward the estimate that she made for the task. Is that estimate still valid, because it seems to be dependent on who she is working with?

Did I read this correctly? It appears to imply that:

  • John estimates it will take 2 days to build a Widget
  • Lisa estimates it will take 7 weeks to fix a bug
  • John and Lisa get together, and decide to work on the bug fixing.
  • 7 weeks occur, and even though the widget isn't started, it gets 7 weeks booked against it.

I haven't read the XP book, but surely that can't be right?

Orion Edwards
Probably not, but perhaps John has experience with that particular type of bug which makes the bugfixing only take 5 days instead of 7 weeks, and this is the problem I have with the assumption that the team can estimate but a developer/pair can execute, it can't be done without wrong results.
Lasse V. Karlsen
A: 

You can create dependent estimates:

If I get to work with Bob this will take 3 days, anyone else 5 days.

I'm not sure I understand the last part of the question, but when a pair get together its on the basis of one developer asking the other to pair. The developer who asks is asking that they work on his task, and they should only work on one task at a time. If they finish quickly, the pair breaks apart and goes their separate ways. If they take a long time, they may break up before the task is finished, and the original developer has to find someone else to pair with before being able to finish the task.

quamrana
This would cause problems on the team "Well Bob is great, but if I have to work with anyone else its going to take me twice as long." People are not going to feel comfortable saying that, and I dont think anybody should be put into such a position.
Nick
Well, I disagree, a close knit team will already know that Bob will be the person of choice with this task. Pairing with Bob on these sorts of tasks should quickly disseminate Bob's expertise. The team should be on the look-out for the quickest way of completing the task.
quamrana
A: 

I didn't see a answer I could agree with, so here is a wiki describing how I now look at this issue.

Practically, the developer responsible for the task will come up with the estimate. Assuming that we can correct that estimate (based on history for that specific developer for example), we can deduce that the longest the task will take is her corrected estimate, since working in a pair will probably allow the developer to finish either on time using her own expertise or faster with the help of the person she is paired with. So in the worst case the estimate is too long, allowing for some slack.

Nick
A: 

One of my basic rules when pairing:

Never ever pair a crack with a beginner. The buddies must be comparable in skill. Otherwise, you will get low performance, frustration and trouble.

So the estimate should come out more or less realistic - no matter who did it.

My personal opinion.

blabla999