Implementing SCRUM…the basics – Part 2

Flickr by drewgstephens
In this post, I explained why SCRUM isn’t a panacea and that there are significant barriers for organizations to adopting SCRUM. This post will introduce Agile estimating, planning Poker, fibonacci and velocity.
Let’s assume that your organization is ready to go. You’ve turned command and controls on it’s ear and identified the Product Owner. Now you’re going be the ScrumMaster. You have assembled a team of experienced developers, a creative design team, and a quality assurance lead. However, the designer and QA lead have never worked on an Agile project, and they have never worked with this team.
Let’s suppose that the Product Owner has compiled a comprehensive list of User Stories. What next?
You need to first work with the “Team” and make sure they understand their responsibilities. This includes talking about being a self-organizing group, that they are responsible to each other, the?Product Owner?and ultimately to the organization for doing what they say they will do.
Next, the SCRUM Team (that’s the development team and the Product Owner) will decide which items from the Product Backlog they’ll deliver in the next Sprint. To do this, you must be able to estimate the time and effort required for each item in the Product Backlog.
This is known as estimation. It is often done by having the development team play a game of Planning Poker.
Are you a gamer? This SCRUM stuff is crazy! Okay, let’s talk planning poker.
User Stories aims to simplify the process of gathering requirements into bite-sized pieces. There will be a variety in the sizes of these bites. This problem can be solved by grading each User Story according its relative “size”.
I think the best analogy is to compare stories to dog breeds. Jack Russel Terrier? Labrador Retriever? Each person must have an idea of the relative “size” for the item. Then, everyone has to play their hand and the group consensus wins.
When?I do this, I am the ScrumMaster. I don’t intend to play a hand because it doesn’t seem fair that I should have any influence on the collective opinion of the team about how big or small a feature might be. To each their own. Mountain Goat Software provided us with the planning poker deck that we used. It was well worth the few dollars it cost. You can also find online versions. It is important to understand the concept of relative accuracy and variability as a feature becomes larger.
The Fibonacci series numbers are probably familiar to you. This series of numbers is used to incrementally scale a feature’s “size”. You may be wondering why this is necessary. If I ask you to estimate in inches the distance between the tip tip of your index fingers and the tip your nose, you’ll probably be able estimate with a greater accuracy than 85%. If I ask you to estimate the distance between the tip of your index fingers and the middle of the letter O on the nearest Stop Sign, depending on where you are at the moment, you might be able estimate with a lower accuracy. Finally, if I ask for an inch estimate of the numb, you might be able estimate with a much smaller degree of accuracy.