Does anyone have thoughts on how to handle estimates when the developers on the team have very different velocities. Like if someone is twice as fast or five times as fast? Many methodologies (whether a waterfall project plan or a scrum task list) have you estimate the tasks. The two alternatives are:
1) estimate assuming a certain person is doing the work and figure out what to do if someone else ends up doing it
2) estimate average speed and adjust when that doesn't happen - which is guaranteed
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.
By the way, Ken Schwaber was in Columbus the other week and gave a presentation at the Central Ohio Agile Association Path to Agility Conference. He said they were working on a number of changes to Scrum including some terminology changes. Some of the ones I remember:
- no more talk about "Pigs" and "Chickens"
- no more commitments to delivering a number of points per iteration/release: teams need to be more honest and give a "forecast" instead to imply that things can still change
Nothing to do really with your question, just thought they're interesting things to note.
Yes, it was quite intriguing to hear Ken talk about some of the things they are working to remove from the "official" recommendations for Scrum. These are from the quickly-scribbled notes I made during Ken's talk:
Removing Sprint Backlog - I'll have to look into this more but I scribbled "composition / decomposition" under this one.
Removing Sprint Burndown - only requirement will be that the team keeps track of the remaining work, that this information is summed up and known daily, and that trending is maintained
Not requiring release planning - up to the team how the want to organize iterations
Changing "Prioritized Backlog" to "Ordered Backlog" - to mitigate the problems caused by having many High Priority items in the backlog
Clarifying the composition of the Development Team - I think this has to do with doing away with Pigs and Chickens. I think they want to clarify the composition of the Development Team; I may be mixing in some previous discussions I've had with other people but testers are supposed to be treated as full-fledged members of the Development Team. Seems like there are many teams out in the wild who still maintain a separation between testers and developers.
Not using Velocity as a predictor -- Aha! This probably invalidates a lot of what I said earlier, except for the last part where I noted a lot of variance in practice.
Not using Capacity -- hmm, can't remember what he said about this one. Will have to look into it more.
The main motivation for changing some of the wording/terminology in Scrum is to discourage sliding back into predictive practices (vs. emergent, iterative, and evolving, I guess) So you have changes like "forecast" instead of "commit"