Once again, I published this on pmstudent.com but thought it would be appropriate to post it here as well.
In this post, I explained that SCRUM is not a silver bullet and that there some significant barriers to entry for organizations wanting to adopt SCRUM. In this post, I'm going to introduce Agile estimating, planning poker, fibonacci, and velocity.
Let's say that your organization is ready to go, you've turned command and control on it's ear, you've identified the Product Owner and you're going to be the ScrumMaster. You've put together a team of seasoned developers, a creative designer, and a QA Lead, but the designer and QA Lead have never worked on an Agile project and they also have never worked with this team of developers.
Let's say that the Product Owner has put together a pretty comprehensive list of User Stories [let's say that for argument sake that these have been validated and prioritized and you have verified that they follow the INVEST principles...more on that in another blog post]. What now?
First, you need to work with the "Team" to make sure that they understand what their responsibilities are, this includes the talk about being a self-organizing team, that they're responsible to one another, the Product Owner, and ultimately to the organization to do what they say they're going to do.
The next step is for the SCRUM Team [that's the development team, the Product Owner, and the ScrumMaster] to decide which items in the Product Backlog you're going to deliver in the upcoming Sprint. In order to accomplish this, you need to be able to quantify how much time or effort each item on the Product Backlog will require. This quantification of the Product Backlog is called estimation and is commonly accomplished by having the development team play a game called Planning Poker.
Game playing? Man this SCRUM stuff is wierd. OK, let's talk about Planning Poker.
The idea behind User Stories is to collect the requirements in bite-sized pieces. The size of those bites will inevitably vary. The Agile solution to this problem is to rate each User Story according to relative "size". The best analogy I've heard is to compare the stories to dog breed...compared to the other stories, if the current User Story a Toy Chihuahua or a Great Dane? Where in the middle...Jack Russell Terrier? Labrador Retriever? Once each person has an idea for the relative "size" of the item, each person has to play their hand, and the group consensus wins...highest and lowest have to explain why they think the feature is larger or smaller than the rest of the team. When I do this, as the ScrumMaster, I intentionally don't play a hand because I don't think I should influence the team's collective insight into how big or small a feature is. To each their own. The planning poker deck we use was purchased from Mountain Goat Software and was well worth the few bucks it cost. There are online versions and of course with a pair of scissors, some index cards, some markers, and a little free time you can make your own. The important part is that you understand the notion of the relative scale of accuracy and the variability that is introduced as a feature gets larger. You're probably familiar with the Fibonacci series of numbers. We use this series of numbers to incrementally scale the "size" of a feature. Why do this at all you ask? Well, if I ask you to estimate in inches, the distance from the tip of your index finger, where it currently is, to the tip of your nose, you will probably be able to estimate with better than 85% accuracy. Now if I ask you to estimate using the same criteria the distance from the tip of your index finger to the middle of the letter "O" on the nearest Stop Sign [depending where you are right now] you might be able to estimate with a significantly smaller degree of accuracy, and finally if I ask you to estimate, in inches, the number of inches from the tip of your index finger to the tip of the Empire State Building in New York City, you are likely to have an accuracy approaching 0%. With this in mind, we use the Fibonacci sequence because as a feature increases in size, our inherent ability to accurately estimate it's size diminishes. After all of the items on the backlog are estimated, the next step is to determine the Sprint Backlog...the estimated subset of product features that will be addressed in the Sprint. We had a hard time understanding how much we could bite off in our first few sprints [in other works, how many "story points"...or Fibonacci values we could consistently complete in a sprint].
In order to get around this, we took two decisive steps. First we committed to micro (one week) sprints and second we intentionally rigged the sprint backlog with items that we knew were small enough to complete in a week, yet big enough to validate [one way or another] our estimates. This process allows us to determine our "velocity". Velocity is the average rate at which a team can complete story points for a unit of time. Once we were able to determine out weekly velocity, we were able to extrapolate our bi-weekly velocity. Once we were able to determine the velocity for a "normal" sprint, we have become increasingly confident in our ability to deliver on that velocity. I will put in a big caveat...the velocity statistic is only a general guide, and as you adopt SCRUM, the accuracy of the velocity is only as good as your ability to limit the variability of external change within the team. In other words, if you determine the velocity for a specific team, that velocity will be affected by making changes to the team, and even in some cases by changes that the team may make from within.
For more information on these topics, there is a great book on this topic written by Mike Cohn called "Agile Estimating & Planning". I highly recommend it.