I’m very excited to let you know that we now have an online course on Agile Estimating and Planning. The course is a series of videos and interactive quizzes. Videos are a combination of screencast (slides) and live action of me. All videos are extremely professionally done–no handheld video camera or recordings of me talking into my iPhone.

The entire course is now available on the Mountain Goat Software site. Check out the free previews. The course can be purchased for streaming or for streaming + download. We also offer group discounts and an innovative, easy way for someone such as a manager, ScrumMaster or similar to buy and distribute licenses to team members.

The 44 videos are interspersed with 9 interactive quizzes. If you miss a quiz question, you get immediate feedback telling you what the right answer is. This approach may not hold up to some certification organization’s rigor, but it’s sure a helpful way to make sure you’ve learned the topic. You can see an example below.

The course qualifies for 4 PDUs from the Project Management Institute and is perfect for PMPs or aspiring PMI-ACP candidates. At the end of the course, you earn a Certificate of Completion as proof of your participation.

Overall this course has been in development for 16 months and we’re hopeful you’ll be able to see the attention to detail we put into it.

I hope you find this news as exciting as I do. Please help me out by spreading the word to your friends, coworkers, grandmothers, and anyone else who might be interested. Thank you.

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don’t rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster.

However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

• Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
• It’s hard to train enough people to do the role well.
• Some people will use their time as ScrumMaster to try to push through changes to the process.
• Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

I’m trying to create a list of the biggest, most common, or hardest to overcome problems that a team might face when adopting Scrum or agile. I could really use your help by contributing to the list by adding a comment to this post. I’m thinking of things like:

• We have five product owners. What do we do?
• We drop work from every sprint. How do we get out of that habit?
• We can’t ever get things “potentially shippable” at the end of a sprint. How can we?
• We spend forever in planning meetings. How can we spend less time doing that?
• etc…

So, what problems have you encountered or heard of teams encountering?

Thanks for your help.

I seem to be encountering more and more people who want to codify agile into a set of rules. I’ve seen this lately in authors of books, blogs or PDFs about agile or Scrum that say “You must do this” or “If you don’t do this or all of that then you’re not doing it right.” Over the last few months I also encountered this in conversations with a few Project Management Offices (PMOs).

That leads me to my new year’s resolution for 2012 and one that I hope a lot of others will make with me: make recommendations not rules.

There are very few hard-and-fast rules to agile software development. I’d put things like:

• work in iterations of no more than a month long
• by the end of each iteration be “done” with something to some pre-agreed upon definition of done and solicit feedback from your key stakeholders on it
• at the start of an iteration, get together and figure out what you’re doing to do during the iteration
• at the end of the iteration, reflect on how well you did during the iteration
• talk a lot during the iteration

Beyond that, it’s much more about recommendations. And there are plenty of things we’ve learned in the nearly 20 years that some agile processes have been around in even informal forms. For example, I recommend teams use user stories as their approach to requirements. I recommend teams use story points for estimating. I recommend that the team pick a day other than Mondays for starting their iterations. I recommend the Szechuan Chicken at Spice China. But, none of these things is required for success with agile. Each may help a team be better, and I have reasons I recommend each. But, these things are not required.

So, my resolution for 2012: Make recommendations not rules. I’d kind of like to make it a rule that you join me in this resolution, but I’ve just resolved not to make such rules.

I’ve wanted to update the design of our Planning Poker cards for quite awhile, and we finally got the chance. The new cards feature an all-new back design to go along with the same faces we’ve used for years.

There are 56 cards in the deck. Thirteen estimating numbers are provided in four colors, each with a matching back as shown above. Additional cards include instructions on how to estimate with Planning Poker and feature full-color photos of goats on the back.

The cards are still the same high quality we’ve always provided. Our cards are manufactured by the same company that provides cards for Caesar’s Palace and other leading casinos. The cards come boxed as before although we’ve updated the art on the box cover–check out the leap of that goat!

Cards are for sale on our store. We will continue to sell our branded cards (like these) at our cost of $2.50 per deck. We also have unbranded cards for sale if you don’t want to see any goats anywhere. And we will continue to sell cards with the traditional goat photo backs as long as our inventory lasts.

Let me know what you think of the new design in the comments below.

People are often surprised that I allow (or even encourage) people to estimate with story points as large as 20, 40, and 100. We include these values in the decks of Planning Poker cards that we sell and give away in classes and at conferences. Yet many people tell me they start out my taking the 20, 40 and 100 cards out of the deck and throwing them away.

I find this unnecessary and, in some cases, detrimental to good planning. These large numbers can play a role in estimating and planning on some projects. Let’s see how.

Suppose your boss wants to know the general size of a new project being considered. The boss doesn’t need a perfect, very precise estimate. Something like “around a year” or “three to six months” is enough in this case. To answer this question you’ll want to write a product backlog. You want to put no more effort into this than you need to. Since the boss wants a high-level estimate, you can write a high-level product backlog. Big user stories (“epics”) that describe large swaths of functionality will suffice.

And these epic user stories can be estimated with the large story point values.

Do you want to do this on every project? No, definitely not. There are some projects where when the boss asks for a plan you better be close. “Heads will roll if you’re wrong,” the boss announces on those projects. On those projects you don’t want to estimate epics and, therefore, won’t use the large values. Other projects (such as contract development) won’t have the tolerance for error that may come when estimating epics and using values such as 20, 40 and 100.

But some projects can tolerate that amount of error in the estimates. Mis-estimating a few epics is probably not enough to change the answer we give a boss who just wants to know if we think a project can be released in Q1 or Q4 next year.

Removing the large values from a deck of Planning Poker cards is like deciding to strike “millions” and “billions” from our vocabulary just because our bank balances are only in the thousands.

I’ve been getting more and more emails lately from people confused about the difference between “user story”, “epic” and “theme.” So I thought his month we’d return and cover some basic–but very helpful–territory by explaining those terms.

First, the terms don’t matter that much. These are not terms with important specific meanings like “pointer” to a programmer or “collateralized debt obligation” to whomever it is that’s important. Story, epic and theme are merely terms we use to help simplify some discussions teams have. The terms do have standard meanings that date back to some of the earliest Extreme Programming (XP) teams. And it’s nice to use terms in industry-standard ways. But, if these terms didn’t exist, you’d make up your own.

So let’s see what each means.

A user story is simply something a user wants. Stories are more than just text written on an index card but for our purposes here, just think of user story as a bit of text saying something like “Paginate the monthly sales report” or “Change tax calculations on invoices.” Many teams have learned the benefits of writing user stories in the form of “As a I so that .” But it is not necessary that a user story be written that way. The advantages of that format are covered elsewhere on this site.

An epic is a large user story. There’s no magic threshold at which we call a particular story an epic. It just means “big user story.” I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There’s probably some car chases, probably some shooting, and so on. It tells you this even though there is no universal definition that we’ve agreed to follow and that an action-adventure movie must contain at least 3 car chases, at least 45 bullets must be shot, and …

So, “epic” is just a label we apply to a large story. Calling a story an epic can sometimes convey additional meaning. Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn’t get the chance to break most of them down into stories that are probably small enough to implement directly.

Finally, “theme” is a collection of stories. We could put a rubber band around that group of stories I wrote about monthly reporting and we’d call that a “theme.” Sometimes it’s helpful to think about a group of stories so we have a term for that. Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme or grouping.

Hopefully you’ve found this short explanation helpful. I look forward to your thoughts.