Recent thoughts on Scrum

In a recent discussion with a seasoned veteran in the project management field, I brought up my recent participation in a Certified ScrumMaster workshop. He asked me what I had found of interest in the workshop material.

One interesting item that had come up in the workshop was that there should be no time limits on scrum planning (aka Sprint 0) – within reason. Obviously there should be a balance struck between scrum planning and the team beginning to build product. However, I chuckled when I heard “no time limits” because in a previous position we were informed by the CTO that Sprint 0 should take no longer than a week for a 4-to-6 month project – no ifs, ands or buts. I regret not pushing back harder on this mandate – the length of time required for project planning depends on the complexity of the project requirements, the familiarity of the team with the existing product and code base, and the number of inter-departmental dependencies involved in the upcoming deliverables, amongst a host of other variables. At a minimum, we should have been taking 2-3 weeks to plan and design for a project of that length.

Another point of interest in the workshop was on agile estimation, and on the value of relative estimation instead of absolute estimation in a software development project. Apparently, most of us are pretty poor at making absolute estimates (“The church is 4.25 km past the Highway 2 intersection.”) and a lot better at making relative estimates (“The church is next to the Best Western, just down the block from the new organic food store.”) So instead of trying to determine absolute estimates from a development team in sprint planning, the Scrum framework encourages the development of relative estimates – estimating the overall work of a user story relative to the smallest story allocated to the sprint. Once the team has determined which story is the smallest, involving the least amount of overall work, estimating all of the other stories can be done relative to the smallest task. (In an ideal world. I believe that there are limitations to this – wildly different tasks within the sprint may not enable direct comparisons, for example.)

One downside of this approach, however, is that in the Scrum framework the team is then encouraged to arrive at a consensus of overall effort on each user story – even though they likely began with a range of effort estimates. For a given story, the initial estimates might be between 3 and 30 days. After some further discussion, perhaps the estimates converge to 8 to 15 days. Although some would suggest that the average be used, or that the team continue to discuss the requirements to arrive at a tighter estimate, I believe there is value in those numbers as they stand. Take the range given and plug the range into your schedule and estimation tools. Perhaps use the same tools provided in the Scrum framework to help your team arrive at three numbers (pessimistic, most likely and optimistic) for each user story instead of one number, and then apply PERT analysis on those three. Chances are your schedules will be more realistic as a result. 

Recognize that the quality of a relative estimate is probably better than an absolute estimate, and that a range estimate is always better than an absolute estimate.

What do you think? What have been your positive and negative experiences with software project estimation, and Scrum?