A key element of Sprint planning is figuring out how much time it will take to complete each Story facing the team. It's human nature to try to quantify "time" in terms of minutes, but that may not always be the best approach.

The team of engineers at open source software vendor Nuxeo uses Scrum for its agile development process. When it comes to figuring out time estimates, team engineer Benjamin Jalon says developers look deeply at the complexity of a Story more than how many minutes they expect it will take to complete.

"So, exactly how can one have a realistic estimation of time required on every engineering task -- specifically, an estimation that will provide a sound basis for planning and an accurate projection of implementation time and costs necessary for our customers to integrate a new feature?" writes Jalon.

"The answer," he says, "lies not in the elements of a single task but in the dependencies that exist within each. This means that a developer must first calculate the complexity of a task. Although he may not know how many hours it will take to complete the task, he knows the complexity naturally."

Certified ScrumMaster and software engineer John Cumming acknowledges it's difficult to drop time-based planning, but moving the focus to the team as a whole and away from individual skill sets makes for a smoother overall estimation process.

“Estimates should stay the same no matter who is doing the task," says Cumming. "That way the velocity also represents the experience / skill level of the team as a whole. If, for example, a team doubled in size with new junior staff, one would expect the velocity to go up, but not to double. So, I think the estimate scale should not reflect individual experience.”

Obviously, there is more than one practical approach to estimation and what works for one team may not work for another. Be sure to take a look at Jalon's and Cumming's posts for some great insight into what works for their development teams.

_{posted by Lisa Hoover (25 Jan 11)}