Estimation Explained

As Tech Republic’s Rick Freedman tells it, every time he posts on an agile topic, the most common argument he hears against agile methods is against the concept of estimation. That is, without exhaustive requirements documentation, how does a development team know what to do or even where to begin? Freedman’s right: This is, by far, one of the most prevalent knocks on agile. But in a post titled “Estimating the Unknown,” he makes a good case for why agile’s lack of comprehensive requirements gathering is nothing to get too worked up about.

According to Freedman, the first things that any development team will ask upon receiving a project are: 1) How much budget do you have? and 2) When does it need to ship? But, interestingly, in a more traditionally managed environment, the team would still put together an enormous list of requirements as if the project’s conditions were not limited in any way. Of course, they are limited—by budget and timeline. As Freedman suggests agile simply rephrases the question from “How much for all these features?” to “How many of these features can you include within this budget and time-box?” In essence, agile acknowledges that work does not occur in a vacuum, but is, in fact, subject to real-world conditions.

What Freedman doesn’t entirely address (he hints at it in the last sentence or two of the piece) is how requirements, like development in an agile environment, are gathered incrementally. That is, agile teams can afford to push some of the requirements gathering to later in the development cycle, when more information about the product is known. During that initial sprint, the team really only needs to know which functionality is most essential to the product—the rest will become clear through sprint review meetings with the Product Owner and customer.

To learn more, watch a Scrum Team conduct story-point estimation during a Backlog Grooming Meeting.

Posted under Agile Methodology, Scrum

This post was written by admin on August 25, 2009

Tags: ,

Lessons Learned from Non-Software Teams

Because agile project management places a special emphasis on the team dynamic (as opposed to the contributions of individuals), I’m always interested to pick up great ideas from hyper-performing teams that work in other fields. This interest started when I had the good fortune to see a presentation by Certified Scrum Trainer Michael James that attempted to uncover the patterns of those teams that seem to achieve the impossible. His examples came from across the board—psychology, avionics, improvisational theater, and jazz. And the patterns he identified truly enlightened what it takes for a team to push itself to evolve into a hyper-productive entity. For example, James found that certain personality types don’t contribute much to team dynamics in which responsibility is shared—and that pairing particular personality types on the same team can be nothing short of toxic. He also found that certain elements needed to be present to keep team members from becoming too comfortable. For example, jazz musicians and improvisatory actors require an audience to elevate their performance. Without an element of risk, such performers do not encounter the threat of failure, which also serves as a compelling motivator. In all, there was far too much in his presentation to succinctly recount here. However, as a frequent reader of his blog, I just saw a similar post, which recommends a short book written by Marine General A.M. Gray which suggests that, for teams engaged in military combat, skill and speed are just as important as size and strength. As James astutely observes, “Effective Scrum teams, with business-savvy Product Owners, have also learned to outmaneuver larger competitors.”

James highlights a handful of especially relevant quotes and provides a link to General GrayÂ’s text online.

Posted under Agile Methodology, Scrum

This post was written by admin on August 12, 2009