Agile Training in Boston, New York City, and DC

AccuRev will be providing its amazing Scrum User Training which is also at an amazing price in Boston, NYC, and DC later this month. If you are considering getting Agile training, you should definitely take a look at this unique combination of content.

AccuRev's Scrum User Training Comes to You!

There are now three cities where you can get an amazing deal on AccuRev Certified Scrum User Training.

This is a unique course that not only teaches Scrum, it also covers the basics of other practices and techniques that you will need to succeed at Scrum. This includes things like user stories, story points, planning poker, continuous integration, unit tests, refactoring, and more!

We initially did these courses on site (which we still do) and are now providing them in cities across the US. The response has been tremendous. People seem to really enjoy this course and have a lot of fun learning through the hands-on activities.

These courses are for everybody involved in development: management, product managers, developers, testers, DBAs, technical writers, project managers, etc. You'll form into cross-functional teams, pick your own software product to build, and do the exercises as a team. This is a great team-building opportunity.

The course is also available for on-site delivery and can accommodate up to 200 participants at a time. Cost is based on an initial fee plus a small additional fee per person and travel and expenses. Instead of training just a small initial team of Scrum Masters, now you can train your whole enterprise for the same price. For more information, contact sales@accurev.com and tell them I sent you! :-)

AccuRev's Scrum User Training Coming to Santa Clara

I'll be bringing our Scrum User Training to Santa Clara on Dec 2nd. It's a full day of hands-on activities that will introduce you to Agile and Scrum. If you've been considering Agile, this is a great way to introduce it to your whole team at an amazingly affordable introductory price.

Dallas: Scrum and Kanban Like Chocolate and Peanut Butter, Sept 15th

If you will be in the Dallas area on Sept 15th, come get a brief introduction to Kanban and see how it may be able to add a little extra flavor to your Scrum implementation. Find out how "One Piece Flow" is key to both Scrum and Kanban, learn about Limited WIP, and how the decoupling principle is a key principle of Kanban that can be easily applied to Scrum. I'll be keynoting with the presentation "Scrum and Kanban Like Chocolate and Peanut Butter" which was standing-room only at Agile 2010.

Come and Re-Examine Your Beliefs at Nashua Scrum Club

It has been a while since I've blogged here. Why is that? Well,  I've been blogging over on the AccuRev site, doing more and more speaking engagements, and twittering like mad. I'll be blogging more here soon. In the meantime, if you are interested in what's been on my mind lately and you are in the Boston/Nashua area, why not check out the Nashua Scrum Club meeting on Sept 9th? I'll be doing a presentation that takes a look at how our beliefs and the beliefs/culture of our team/organization/customers influences the success and failure of Agile adoption. Hope to see you there!

Mary Poppendieck to Speak. Waltham, MA Jan 7th, 6pm

As I write this, 52 folks have already registered for Mary's talk and there are only 120 total spots available. Her talk is titled "The Leadership Team and the Software Crisis: A Cautionary Tale" . Mary's talk will tell the story of a large company as it attempts to turn theory into practice, uncover barriers to sustainable change, and look in unexpected places for the root cause of the software crisis. She will also discuss governance and the role of the leadership team in developing software-intensive systems.

If you've never heard Mary speak, now is your chance. She's a terrific speaker who always has great material. And to top it all off, this event is not only free, dinner is included!

Registration has only been open for a couple of days. If you are thinking of going, now is the time to register!

Second Edition of "Do It Yourself Agile" Available as Free Download

At the beginning of the month I released the first version of "Do It Yourself Agile." The response was tremendous and I am very grateful to the many people that blogged and tweeted about it. I am also very thankful for all of the feedback and suggestions that I have received. In total, the book has now been downloaded more than 4,000 times.

Here is the second version, which takes into account all of your feedback and also incorporates new sections based on recent blog posts. Please keep the feedback coming. If there is something you feel is missing, let me know. New material usually starts out as a blog post first, so you'll get immediate feedback.

While I believe that an Agile coach, whether recruited internally or externally, is still the best, fastest, and least expensive (in terms of ROI) path to Agile success, not everyone can do that. It may be politics, budget, or some other reason that prevents folks from using seasoned coaches. In any case, DIY Agile is here to stay, and the book "Do it Yourself Agile" is intended to be a resource you can lean on as you transition to Agile on your own.

Let me know what you think. I look forward to producing more versions incorporating your feedback.

The book is freely downloadable, no strings attached. I only ask that if you point people to the book, please point them to this blog post rather than linking directly to the pdf, copying the pdf, or providing the content in some other format.

"Do it Yourself Agile" (pdf) 180+ pages

"Do It Yourself Agile" - condensed web version

Planning Poker Reduces Risk and Waste

There are three particularly valuable things that can happen during a Planning Poker session. They may also happen during any flavor of estimation meeting, but seem to be more likely when using Planning Poker.

The Bigger They Are, The Harder They Fall

I recommend that you never use a story size greater than 13. Most stories that are estimated at 8 points or above can be split into smaller stories. You should always be looking for opportunities to break larger stories into smaller stories. If you have an 8 point or larger user story, it is probably actually two or more stories in disguise. The bigger the story, the more likely your estimates are wrong and the more likely that you have many smaller stories masquerading as one large story.

For instance, you may find that a story that originally looked like a 20 point story was really two 8 point stories, one 5 point story and 2 three point stories for a total of 27 story points. Better to break that huge story down into its five constituent stories and estimate them each individually.

But remember, a story is only a story if it provides value to the user. Splitting a story up into “As a user I want the backend for X” and “As a user I want all of the UI for X” is not the right way to go. If you can’t create smaller stories that still provide user value, then the story is already as small as you currently know how to make it.

Know When to Walk Away

You may realize while discussing a story that the story contains a big unknown, something that feels like it won’t be resolved during the implementation of that story. In that case it is best to split the story up into a research story and the story itself. For instance, “As a developer I want to know how to XYZ.” That way, if you never do figure out how to do the unknown part, you haven’t invested any effort into the overall story. This technique should only be used as a last resort, but it is much better to do this than to know going in that there is a big unknown and have to pull the whole story out near the end of the iteration.

Know When to Fold’em

Lastly, you may decide that you just don’t have enough information to estimate a story. In that case, you should have a mechanism for informing the product owner such as marking the story “need more info.” There’s no point spending time on estimation if there is insufficient information to do so. You’ll just be glossing over the problem and producing a false sense of security.

Breaking out research stories and kicking stories back to the product owner may seem like procrastinating, but it tends to build good habits. It keeps the team from committing to work that includes research projects, clearly defining some stories as research stories, and keeping the product owner on his or her toes.

Counting Your Chips

In summary, if you are mostly working on small user stories that have end user value, you are reducing the chance that you are putting something into the product that never gets used and you are also reducing the chance of starting work on something that never gets finished or has to be discontinued part of the way through. The smaller your stories, the smaller your risk and the less effort you’ve wasted when you run into problems.



See Also: "The Five Essential Ingredients of Great Agile Estimation"

The Five Essential Ingredients of Great Agile Estimation

Planning Poker is a useful Agile estimation technique (see previous post "Introduction to Planning Poker"), but it is even more useful when used in conjunction with whole teams, user stories, velocity, and story points. I refer to these five practices, used together, as the five essential ingredients of great Agile estimation.

Whole Teams

A key practice of Agile development is the use of whole teams. A whole team is a cross-functional team comprised of between 5-9 people. By cross-functional I mean the team as a whole contains all of the skills needed to accomplish the team’s goals, not that each team member is capable of doing any task. If you have more than 9 people, then you split people up into multiple whole teams.

Planning Poker reminds everybody that the estimate includes all of the work that needs to be accomplished in order for the story to be considered done. It includes development, testing, documentation, and anything else required for the story to be considered done. It is a reminder that nobody on the team gets credit for a job well done until the whole story crosses the finish line. Instead of people saying “well, I finished the development, I don’t know what is taking the tester so long” they are more likely to say “what problem are you running into and how can I help?”

User Stories

Because user stories are a simple and easy to understand description of the work, user stories allow you to focus on estimating rather than spending lots of time discussing what a particular enhancement request or requirement really is. To maximize the benefits of Planning Poker, you need to be good at creating and using user stories.

Story Points

In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.

On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.

To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.

Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of an iteration by calculating a velocity.

Velocity

In Agile, the velocity of a team is simply the number of story points associated with stories that are finished in an iteration. For instance, if the team completed 8 stories that were each 5 points in an iteration, then their velocity for that iteration was 40 story points. In a stable team, a team that is comprised of the same individuals working full time as part of that team, the velocity is a good measure of the overall throughput of the team.

Knowing your velocity helps with planning. For example, if you know that the velocity of your team is 40 points, then you know you can expect 40 story points for each iteration. The team decides which stories to take based on the backlog which is maintained by the product owner.

More Than the Sum of The Parts

Regardless of which of these practices you are currently using – whole teams, user stories, story points, velocity – Planning Poker is an excellent tool. The more of these practices you use, the more they reinforce each other and the more value you will get out of Planning Poker. Conversely, the more you use Planning Poker, the more value you will see in implementing all of these practices.



Next: Planning Poker Reduces Risk and Waste

Introduction to Planning Poker

Many of the techniques of Agile development combine together to provide more than the sum of their parts. One technique that definitely fits this description is the Planning Poker method for doing estimation. In part 1 of this post, I will quickly describe the mechanics of Planning Poker. I will then go on to describe how user stories, whole teams, story point estimation, and velocity all work to multiply the value of Planning Poker and how Planning Poker also reinforces the use of and value of the other practices. If you are already familiar with Planning Poker, you may want to skip ahead to "The Five Essential Ingredients of Great Agile Estimation".

Planning Poker is an estimation technique first described by James Grenning in 2002 in a paper by the same name [pdf]. When I first heard about Planning Poker, I couldn’t help but chuckle. It seemed a bit silly to mix software development and poker. After reading Mike Cohn’s excellent book “Agile Estimating and Planning” I had a good grasp of the mechanics of Planning Poker, but it felt like just a variant of the Delphi method and thus nothing new.

About a year ago we had Kenny Rubin come in to do some Scrum training for us. That was just the shot in the arm that we needed to supercharge Agile adoption at AccuRev. If you are looking for an Agile trainer, I highly recommend Kenny Rubin. It was based on Kenny’s explanation and recommendation that we decided to try Planning Poker on a real project. The results were terrific and after a single session we were hooked. Planning Poker is now a standard part of our Agile process.

The Basics
In order to play Planning Poker, each participant will need a deck of Planning Poker cards. These are easy to obtain, just Google for “Planning Poker cards” or make your own. You will need the following cards: ½, 1, 2, 3, 5, 8, 13, 20 and a card that indicates “I’ve had enough.” The numbers on the cards represent estimates. You can use story points, ideal days, or some other measure, but in this point I am assuming (and advocating) story points. Typical decks contain cards for much larger numbers than 20, but I think you’ll find that 20 and higher are rarely used once you’ve been using Planning Poker for a year or two.

The whole team gets together for a set amount of time to do story estimation. An hour is usually a good amount of time, but this is completely up to you. When I say “the whole team” I am assuming that you are using small cross-functional teams of 5-9 people (see later parts that discuss the use of whole teams).

Estimation is done on a story-by-story basis in the same order as the backlog, starting with the first story that needs estimating. Somebody reads and describes the story. This is often the product owner, but could be anybody. Some teams do story point estimation without the product owner and just skip stories which they are unable to do without the product owner’s involvement. After the story has been read, participants discuss the story for a bit and then decide on an estimate by picking one of their cards and laying it face down in front of themselves. Once everybody is ready, all of the estimates are shown. If the estimates are all the same, you are done.

Usually, some of the estimates are particularly low or particularly high. A low estimate can indicate that the estimator left something out, or possibly that they know a way to reuse existing work or have some other good information that other folks weren’t aware of. A high estimate may indicate many things, but most commonly it means that the estimator is thinking of something that other folks may not be aware of. For instance, somebody may point out that there is no test framework or tooling for a particular technology and that to adequately test the story the team will need to do a lot of setup work.

In any case, after a round of discussion, everybody chooses a new estimate. This is repeated until the team comes to consensus on the estimate. The estimate is given to the story and then you move on to the next story. You end when you hit the end of the meeting time, you run out of stories to estimate, or somebody plays the “I’ve had enough” card.

The Benefits

One of the biggest benefits of Planning Poker is the sense of team that it creates. The whole team is participating in the estimation. This creates a greater sense of team ownership and team responsibility for each story. Another major benefit of Planning Poker is that you leverage the collective wisdom of the whole team. However, this really only works well when you are using whole teams in the Agile sense of the term.



Next: The Five Essential Ingredients of Great Agile Estimation