Daily Scrum: Not Just for ScrumMasters

I never refer to the daily scrum (or daily standup) meeting as a “status meeting.” The term “status meeting” is too pejorative for most of us. For me it conjures images of sitting around a table with each person giving an update to a project manager while everyone else feigns interest while either mentally preparing for their own upcoming update or wondering how much longer...

GASPing About the Product Backlog

I’ve been wondering lately if Scrum is on the verge of getting a new standard meeting–the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the...

Agile Succeeds Three Times More Often Than Waterfall

Agile projects are successful three times more often than non-agile projects, according to the 2011 CHAOS Manifesto from the Standish Group. The report goes so far as to say, “The agile process is the universal remedy for software development project failure....

Estimating and Planning Are Necessary for Maximizing Delivered Value

Because I’m so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, “Estimating is waste! Don’t do it!” The thing that never shocks me about these arguments against estimating...

Rotating the ScrumMaster Role

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...

Please Help Me List the Problems with Using Agile or Scrum

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...

Recommendations not Rules

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...

New Planning Poker Card Design

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...

In Defense of Large Numbers

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...

Stories, Epics and Themes

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...

Simulating a Project by Resampling Velocity

I normally write about a new technique only after I’ve used it for a couple of years and have found it successful in a couple of different contexts. In this post I want to share something just such a technique. It’s a statistical technique called “resampling”...

Seeing How Well a Team’s Story Points Align from One to Eight

The topic of how well a team estimates two point stories relative to one point stories (and so on) has come up in a couple of comments and replies on this blog recently, so let’s discuss it. Here’s a graph showing relevant data from one company: Each...

Estimating a Full Backlog Based on a Sample of It

I want to address a question I was sent recently and that I get asked about once a month. The question has to do with how we estimate how many hours it will take to deliver a given product backlog if we have no historical data at all. My first bit of advice...


There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA