posted 11 years ago
Yeah, that's always a sticky problem. I think a common approach is to have the team estimate the story points using Planning Poker or T-Shirt Sizing. The story points represents a relative size compared to a baseline story for which the effort is already known and understood, rather than just raw time estimates. To facilitate point sizing, you usually task out the stories without time estimates for those tasks. The trick here is to have a good idea of the team's average velocity in terms of story points per timebox rather than just plain time. In theory, if you stick with story-points/timebox, the variances between how fast or slow each developer works is evened out because you are now looking at the velocity from the team level. The analogy is this:
If you have a pile of rock to move from one place to another and you have 3 bulldozer drivers with different expertise levels who do the work at different rates, how do you estimate how long it will take them to move all the rock? Well, you look at their past work. Let's say the same crew moved another pile of rocks the day before. You look at that pile of rocks from the day before and compare it to the pile of rocks they need to move today. That will give you a pretty good read on the amount of effort it will take them, as a team, to move the new pile of rock. So if the baseline pile is half as big as the new pile, it will probably take the crew two days to move the new pile. Likewise, if the new pile is half the size of the baseline pile, you could probably reasonably expect the crew to move the pile in half a day. How fast or slow each individual works does not matter too much anymore because you look at it from the macro level: at the capacity of the whole crew.
So, piles of rock == piles of stories. story points == relative size of the piles. day == sprint timebox.
You pick out a set of stories whose points add up to the total number of story points the team has historically delivered in a timebox and allow the team to work only on those stories.
To keep a pulse on the teams progress throughout the timebox, you have each developer sign up for a story or a number of stories, and give their individual estimates of how much time it's going to take them to finish each task. The total of the task estimates of all the stories should be reasonably close to the number of hours the entire team can devote to focused work during the timebox. We usually estimate about 5 hours per day of focused work to accomodate for time spent in meetings, phone calls, and answering emails. If the team gets distracted a lot, you reduce those hours. This helps you see if you underestimated the level of effort it would take to get the stories done.
That's the theory at least. In practice, I find that there can be a bit of variance, sometimes big, sometimes small, in the velocity of a team. Even when the team members are the same, velocity from one sprint to the next and one release to the next can still vary widely. The problem is that there are a lot of factors that contribute to the variance. These are people, not robots. Their performance varies over time. Moods, personal circumstances, health, vacation, and a whole slew of other things can affect each person's productivity. It's nice to have consistency but you often can't reasonably expect it. Imagine how difficult it gets when the team isn't 100% dedicated to the same project or if team members come and go frequently. Like I said, it's a sticky issue and one that's not easy to get a handle on.