Mike is a founding member of the Scrum Alliance, Inc. and currently serves as secretary on the Board of Directors. He founded and operates Mountain Goat Software, a process and project management consultancy and training firm.

Mike has over twenty years of experience in a variety of environments and specializes in helping companies adopt and improve their use of agile processes and techniques in order to build extremely high performance development organizations. He has previously served as a technology executive in organizations of various sizes, from start ups to Fortune 40 companies. Mike ran his first Scrum project in 1995 and has been a vocal proponent of Scrum ever since. He has helped with the adoption of such processes at numerous companies, including Bioware, Capital One, Electronic Arts, Google, High Moon Studios, Intuit, JDA Software, Lexis Nexis, Lockheed Martin, Microsoft, Nielsen Media Research, Pearson, Phillips Electronics, Sabre, Siemens, Sun Microsystems, Texas Instruments, Turner Broadcasting, Ultimate Software, and Yahoo.

Mike is a frequent featured conference speaker at industry events and a recognized magazine contributor. He has authored numerous books, including Agile Estimating and Planning, User Stories Applied for Agile Software Development, and Succeeding with Agile Software Development using Scrum, as well as several books on Java and C++ database programming. In addition to his service with the Scrum Alliance, Inc., Mike was also a founding member of the Agile Alliance and is a member of IEEE Computer Society and the ACM. Mike is a Scrum Alliance Certified Scrum Trainer.

View on map

Upcoming Courses by Mike

Course Type Custom Title Date Range City
Certified ScrumMaster 23-24 Aug 2010 Dallas
Other Succeeding with Agile 25-26 Aug 2010 Dallas
Certified ScrumMaster 13-14 Sep 2010 Cupertino
Certified Scrum Product Owner Certified Scrum Product Owner 15-16 Sep 2010 Cupertino
Certified Scrum Product Owner 20-21 Sep 2010 Oslo
Certified ScrumMaster 22-23 Sep 2010 Oslo
Other Succeeding with Agile 24 Sep 2010 Oslo
Other Effective User Stories for Agile Requirements 11 Oct 2010 Boulder
Certified ScrumMaster 12-13 Oct 2010 Boulder
Other Agile Estimating and Planning 14 Oct 2010 Boulder
Other Agile Estimating and Planning 18 Oct 2010 London
Certified ScrumMaster 19-20 Oct 2010 London
Other Succeeding with Agile 21-22 Oct 2010 London
Certified ScrumMaster 8-9 Nov 2010 La Jolla
Other Succeeding with Agile 10-11 Nov 2010 La Jolla

Recent Articles by Mike

Scrum Shouldn't Be a Burden 20 Mar 06

If lightweight processes feel too heavy, it's most likely an implementation problem.

Resources by Mike

Scrum Smells: An Initial Catalog
by Mike Cohn This article was written for the Scrum Alliance soapbox. It presents an initial collection of Scrum smells or indicators that things may be amiss on a Scrum project.
Introduction to Scrum Methodology
This is a 60-90 minute introduction to Scrum that is fully redistributable and reusable. Use it to introduce Scrum to your user group or organization. Provided as a PowerPoint file so you can customize. Please acknowledge the source but please use...
Prioritizing Product Backlog_Cohn
Fall 2007 Scrum Gathering: London  Wednesday, 14 November, 10.45-12.15 “Prioritizing Your Product Backlog” Presenter: Mike Cohn, CST, Mountain Goat Software, USA The biggest risk to most projects is building the wr...
Guide to Transitioning_Cohn
Fall 2007 Scrum Gathering: London Wednesday, 14 November, 15.30-17.00 “Succeeding with Agile: A Guide to Transitioning” Presenter: Mike Cohn, CST, Mountain Goat Software, USA Transitioning to an agile development proces...
User Stories
Prioritizing Your Backlog
Leading an SOT Team
Presented by Mike Cohn at the 2009 Orlando Scrum Gathering

Recent Comments by Mike

On Language for Discussing Releases
There are some great ideas in here, Dan. Thanks for sharing them with us. You are very right that it is hard to give a project stakeholder a message like "We'll be late." We should probably all practice saying that 100 times in the mirror each mor...
On Advice on Conducting the Scrum of Scrums Meeting
Hi Matt--I'm not sure if I understand what you mean about the Scrum of Scrum being used for individual team planning to ensure requirements and roadblocks are addressed. A lone team on a desert island wouldn't have a need for a Scrum of Scrums mee...
On Advice on Conducting the Scrum of Scrums Meeting
Replying to the two previous comments: First, if two different participants disagree they need to work it out with the help of other participants. This is part of becoming a self-organizing team. Second, Yes, the Scrum of Scrum participants will...
On Advice on Conducting the Scrum of Scrums Meeting
Thanks, anonymous. Your constrained-but-leave-time-after approach is essentially what I do. We try to get a quick update from everyone, go over some basic sharing and then dive into specific issues to be resolved. Some people will opt out if they ...
On Leader of the Band
Since a ScrumMaster is a part of the team, he or she is held accountable for the success of the project but only to the extent that every team member is. The ScrumMaster should not be singled out for any special recognition or blame in the event o...
On Perfect Planning
Guy--Nice article. It should be pointed out, though, that the Kanban approach of Anderson and Garber was used for sustaining engineering (aka "maintenance") efforts. I've worked with many teams who plan sprints in the typical agile manner but also...
On Scrum Alliance Certifications
Hi Plamen--There is indeed a Certified Scrum Product Owner. A couple of sessions are scheduled for Europe over the next few months. In fact, there's more in Europe than in the US between now and the end of the year. Within the next month or two th...
On Case Study: October 2007
One of the things I like to suggest when a team has to drop items from a sprint is that they plan sufficiently fewer hours in the next sprint so that they are nearly certain to be able to finish the work of that sprint without dropping work. I don...
On Writing the Product Backlog Just Enough and Just In Time
Hi Haim- I'm glad you found this article helpful. I have teams estimate with the sequence of values 1, 2, 3, 5, 8, 13, 20, 40 and 100 (story points or ideal days). I ask them to think of those numbers as buckets. A 13-liter bucket cannot hold a 1...
On Writing the Product Backlog Just Enough and Just In Time
Hi Geir--It sounds like you've discovered some great subtle ways to improve things for your team. That's fantastic.
On Writing the Product Backlog Just Enough and Just In Time
Hi Mike--It is amazing how even a little bit of visibility (e.g., upcoming cards posted to a nearby wall) can really help the team.
On Writing the Product Backlog Just Enough and Just In Time
Hi Cindy-- I don't exactly follow what you do. From the above it sounds to me that you are doing something similar to what I advise, which is (a) writing product backlog items at different levels of detail based on things such as priority, risk, ...
On Scrum Shouldn't Be a Burden
Hi James-- You are absolutely correct. I've been working on a new book and in it I describe five steps or phases that I've noticed occur in successful transitions. The final phase is what I call "Transfer." It refers to the need to transfer the...
On Writing the Product Backlog Just Enough and Just In Time
Hi Anthony-- Usually when a team puts a "?" as the estimate on a story it means they don't know enough about it at the time to estimate it. The solution is usually to get more information from the PO about what to build or to develop more technica...
On Writing the Product Backlog Just Enough and Just In Time
Hi Rachel--I'm glad you liked the article. Yes, for most teams I work with a 13-point user story is achievable within a two-week sprint. That's on the upper end of what most teams can do in a sprint. I often ask product owners to spend some time a...
On Writing the Product Backlog Just Enough and Just In Time
Hi Jay--You are absolutely right. I find that the exact same advice I give to User Experience Designers is what I say to architects: "Just in time, just enough." Some things need to be thought through more than others so do so when there will be v...
On Writing the Product Backlog Just Enough and Just In Time
Hi Andrea--Thanks for sharing this description of your approach. This sounds very interesting.
On Writing the Product Backlog Just Enough and Just In Time
Hi Andrea--I can't take credit for inventing any of those ideas. User Stories come from XP and its inventors, Kent Beck, Ron Jeffries and Ward Cunningham. The term "Planning Poker" was originally from James Grenning. And I think Relative Estimatin...
On Advice on Conducting the Scrum of Scrums Meeting
Hi Tara-- This sounds like a very interesting approach. I'm a fan of anything that makes things visual. Thanks for sharing this.
On Advice on Conducting the Scrum of Scrums Meeting
Hi Chandresh-- I'm with you. If the team doesn't want that meeting (and they are experienced enough to make such decisions intelligently) then the ScrumMaster should find another of getting whatever information he needs. I tell ScrumMasters their...