Sprints Are Dumb

I should probably qualify that statement a bit. A common term used in the Agile (Scrum) methodology is the “sprint”. It is an interval of time planned to complete some defined amount of work. The use of this term with respect to Agile is dumb. Why? The purpose of the Agile methodology is organize around a team and work at a pace that could be continued indefinitely. A software development project is a marathon and you certainly cannot sprint throughout a marathon.

They Are Also Dangerous

We have all been there, I am sure (if not, you will be there at some point). You have a stakeholder that is motivated to complete a project, which is good news. However, this particular stakeholder sees the word sprint and reads into the meaning what I think many would have at first glance. “Why aren’t we working faster?” This is not the point of a sprint.

“Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon” (Martin, 2019).

I read that footnote in “Clean Agile: Back to Basics” and knew there was a reason that I frequently return to Uncle Bob for advice. He confirmed my sentiment exactly.

Using a word matters because a word has meaning. We should use a word when we intend to use its meaning and refrain from using it otherwise.

The Iteration

The alternative proposed by Uncle Bob is an “iteration”. In Agile methodologies, work is planned around the interval that has been commonly called a sprint, but we will henceforth call an “iteration”.

An iteration will be some specific amount of time that is repeated. Commonly, this period of time is two weeks. Practice suggests that this is a good duration for intervals in most projects. Anything shorter would not yield enough results for the overhead and anything longer would tend suffer from Parkinson’s Law.

The Zeroth Iteration

This first iteration is the “zeroth” iteration. This iteration is dedicated to planning the first iteration that will have work being produced. Each iteration should start with an Iteration Planning Meeting (IPM) that is about 1/20th of the duration of the iteration, so a half a day, normally. During this meeting, the stakeholders meet and brainstorm the various user stories that should be included in the project with a specific intent for stories to be completed during the first iteration.

The user stories should be concise and without detail. Martin suggests a few user stories for developing software for an ATM:

  • Login
  • Logout
  • Withdrawal
  • Deposit
  • Transfer

That is all the description that should be included because it is highly likely that they will change. Perhaps some of the stories will be split, others may be combined. No sense in spending time being verbose when it could easily be discarded.

Next, each of the stories should be rated for difficulty. The first stories should be chosen as representative of an average difficulty. The remaining stories should be rated relative to the first story. Uncle Bob suggests a scale of 1-6 because it is simple and there is not really any value in being dubious here.

The remaining tasks include categorizing the stories in an Eisenhower Matrix comparing cost and importance. This should guide the prioritization of the stories. If something is highly important and lower cost, it should be done right away, followed by highly important and high cost, then lower importance and lower cost. Items that are categorized as lower importance and higher cost probably should be discarded or at least prioritized to the very end; if you have trouble accepting that, then it these stories are probably improperly categorized. We choose the first stories based on the matrix and any required dependencies and those are the stories for the first iteration.

There will be more discussions to plan this out until the zeroth iteration is complete.

The First Iteration

Now, an IPM is held at the beginning of the first iteration to plan out the endeavor. The scores, or points, for the work items in the iteration are added up and the plan is to complete all of those work items within the iteration. The work items need to be assigned. After the IPM, work begins.

There is no statement of guarantee that the work items will be completed during the iteration. It is a swag of an estimation that is meant to deliver data about the velocity of the project.

Halfway through the iteration is midpoint check. The team should have earned about half of the points for the iteration by now if the estimate was on target. It likely is not. This should give a good sense of what the second half of the iteration should produce, however… roughly the same number of points.

At the end of the iteration, the points should be added up and we have a far better estimate of the velocity of work that can be completed in an iteration. Further iterations should have about the same number of points.


An iteration is a far better term for the work interval in an Agile project than a sprint. The word is more representative of the matter at hand and contributes to a well functioning team that is not being driven unrealistic expectations. Each iteration provides data that is used in planning subsequent iterations. No iteration is a failure.

Martin, Robert C. Clean Agile. Pearson, 2019.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s