Perry, the Product Owner: "How long will it take to implement the XYZ feature in the ABC project?"
Sam, the would-be Scrum Master: "Uh... I'll ask the team and get back to you".
Having flipped through a few books on Scrum, Sam heads off to the team room and asks the team to estimate.
Sam, returning with an answer: "A week, but remember this is just and estimate".
Perry: "Sure, sure. Great. Thank you".
Sam, being in tune with the Force, feels a cold wind on the back of his neck.
End of the iteration comes, and the feature took ten days to implement.
Perry: "You said it would take 5 days. It took 10! What gives?"
Sam: "Hey, I told you, it's just an estimate!"
Perry: "Estimate, okay. I expected up to half again, and padded accordingly, and billed the customer. But you took double! Your estimates are worthless!"
What's the trouble here? Was Perry wrong to use the estimate? Was Sam wrong to give it?
I think not. I think the problem lies in their failure to communicate needs and expectations.
Here's a stab at how the conversation should have gone:
Perry: "How long will it take to implement the XYZ feature in the ABC project?"
Sam: "Why do you need to know? Let's take care of this at the Sprint planning session".
Perry: "Well, I've got a customer who wants a patch with that feature. I need to know what to bill him".
Sam: "I see. And do you have to know the amount of time it will take, in advance?"
Perry: "Duh! How else will I bill him?"
Sam: "Hmm... Do you bill him by the hour? days?"
Perry: "No, but a small feature will cost differently than a large one. And a customer needs to know what he's paying for".
Sam, smiling, as he already has the answer: "So, you're saying that you're charging on a scale, right?"
Perry: "Right."
Sam: "Well then, why not charge based on the size of the feature?"
Perry: "Aren't you listening? That's what I'm doing!"
Sam, grinning broadly: "Then why didn't you ask me what size the story is, instead?"
Perry: "Because you already told me before the last Release Planning session, that it is 10 story points..."
Realization dawns on Perry's face.
Sam raises an eyebrow.
Perry grins sheepishly, and slaps his forehead. He turns away shaking his head, and heads towards the place where all POs go...
Sam congratulates himself and rides off into the sunset...
The most important thing to understand about estimation, is the reason for it!
In my experience, there are two reasons to make an estimation:
- To bill a customer, in a time-based (cost) project.
- To know when the next version's release date will be. Gotta keep them bosses happy.
- Prioritize features - often. we'll want to release something small earlier.
Here's a short list:
- Understanding the requirements - often the needs are unclear, volatile or both.
- Understanding the technology - frameworks, especially for enterprise applications are too vast and complex for anyone to truly understand all of it. Thus what one needs for a project, he may often learn for the first time while on the job.
- Who does the job - in all but the simplest tasks, software development is done by a team. A team is made of heterogeneous members, each with different skills, and different knowledge. What may take one person 1 day could take another 2 days, and vice-versa.
- etc.
The simplest way to increase our accuracy is to eliminate one of the variables: skill. What we're left with is a need for a complexity-based estimation method
Enter the story-points.
Continued in the next part.
רשומות
0 תגובות:
הוסף רשומת תגובה