Giom Duquesnay

Avoiding confusion about what iterations means

In agile, we call Iteration a fixed time period. In Scrum (one of the agile methods), an iteration is called a Sprint. By that we mean a fixed cadence of work.

I witnessed several trainings struggling on the same topic, trainers and attenders alike. I heard many people I coached mixing notions right out of a Scrum training.

So let’s see if we can spell out this confusion for the future.

Overusing the Sprint / Iteration words

Many times I hear the word sprint used for “a fragment of the product” or “an amount of work to do”. I guess it’s originally a shortcut from “fragment of product done in the time of a Sprint”, or “amount of work planned for the time of the next Sprint”.

However, for someone not used to agile, it’s confusing. Trainer said it’s a fixed time period. Then trainer seems to say it’s an amount of work. There’s something that magically make an amount of work fit in a fixed time frame. Coz for someone discovering agile it’s painted with mystery.

In a recent training our attenders where from waterfall world (where you plan according to effort), and started ask questions mixing notions of effort and time. The other trainer and I have been paddling for 20 minutes not knowing why our trainees kept mixing notions despite our explanations… until I realized we abused the meaning of iteration. So much for clarity.

The trainees didn’t see that in Agile we are now planning in term of time box, giving a pace of work where the amount of result is variable. In their previous world you start planning from effort that will span in phases of variable durations.

Classic check that you failed to lead to cadence thinking

If you don’t sort this early, later on the project they will be surprised when through the course of a sprint (again, a fixed time cadence) throughput don’t go as planned. They weren’t prepared for that since they weren’t driven away from there previous “effort” frame of reference. Again, they’re confused.

Usually I let it go since after a few sprint they will get it, but in the meantime they struggle and they are unable to explain it to other project partners and stakeholders that are not used to agile projects.

Well, they get it… actually I’ve seen Product Owners and even Scrum Masters still mixing notions after a year. I also saw agile veteran projects, year longed, intoxified by the notion of planned throughput.

A few classic tense to avoid

Guess what ? I saw coach and trainers also not being able to precisely sort the notion. (yes, me angry here)

Here’s a few quotes I heard from trainers that led trainees into mixing the two notions

• “you did all the Sprint”, “you didn’t do all your Sprint”. Of course they did. How could you fail or succeed 2 weeks? Instead, you can say you achieved in the course of the spring less than you predicted, or more.
• “let’s plan your releases into iterations”. You just can’t decide that. Instead, you can say (after the project has acquired its rhythm), “let’s try to predict what will be done at each iteration”.
• “we will report the sprint on the next sprint”. Again, it may be just that you are shortcutting words, but for those discovering agile, it’s confusing. Instead you can say “During the next sprint we will work on the user stories that aren’t Done”

Avoiding the big trap of the initial project -planning-

After starting to spot the confusion, I realized it came mostly during the first initial roadmap creation, and can be avoided there.

Today I pay great attention to not use the notion of time when doing the first story map and roadmap definition (inventorying the project features scope and setting it into successive interesting releases).

By extension I don’t use the word iteration or sprint either.

I carefully choose my words since it may be that my coachees has been misled during a previous training (more on that later).

So far, it works, I have very little questions that mixes the nations. So the confusion went from me.

Practically :

when I do a roadmap, I ask the product owner to prioritize items typically by one of these two strategies :

• “Buy a feature” exercise

“If you could have 3 of these features in short term (or Epic, or macro-story whichever terminology you use), which one would you like to see done and working ? Then which ones would you pick next ? etc”. See ? Sequence thinking, but no notion of time.

• Dichotomic prioritization

“here’s a line, this is your mid-project. What would you see first ? What would you see next ?” (you can also use “must have / should have / why not, or any criteria to make prioritization happen)

Then I draw another line in the middle of the first and second quadrant. (interesting variant : I draw 4 lines and ask for 4 releases directly ; let’s not digress)

At this time, I never introduced the notion of When things are going to get done. Only what should comes first.

The notion of time will only be introduced on a next estimates workshop. Then I will follow the advice of J.Rothman and only use the words predictions.

Erm, Scrum industry, wtf ?

You mind if I end with a rant ? Gotta unload my heart. It was my first impulsion into writing this.

Scrum industry, you’re a powerful machine, you help popularizing agile and raise new generations of Agile Trainers and coach by the hundreds. But when you fuck up such detail we coach in the field have a hard time cleaning up the mess.

And no, don’t look away, the mistake can’t be made in flow-style Agile (Kanban and such) since we just speak about cadence and don’t even talk about iterations planning. I spotted that constantly will people coming out from various Scrum trainings.

So to my beloved pairs teaching Scrum : can you check that the confusion of iteration = time is not engraved in your training slide ? Thank you very much

Bisous bisous

by Giom Duquesnay