You’re Doing It Wrong: Iteration Planning

This series is about practices we do, without understanding why we do them, and therefore may not get the value we want from them. If you too don't benefit from them, you might be doing it wrong.
Iteration planning, Pt. 1 Iteration planning, Pt. 2Definition of doneDemo
Done-DoneDaily stand-upsRetrospectivesContinuous integration

YodaPlanWhy do we do the things we do?

When we can explain why we d: practice, decide to keep or change the way we do things, we should have better excuses than “that’s the way we’ve always done it” or “it is considered a best practice”. If these are the only answers we have, we’re in a bad place.

In fact, if we continue to do things without understanding why, not only will we not understand why they go wrong, we can’t do course correction in order to improve the situation.

In recent years, we’ve heard stories about “cargo cult“, people continue doing the same things that worked before, but because circumstances have changed, the practices are not useful anymore. Too many times we follow the scrum (and other methodologies’)  practices, and people continue to get surprised at the results.

So let’s explain the “why”. This will turn out to be a series, so watch out.

And let’s start with the trigger to the series.

What’s the plan?

Planning, estimation, and all ways of predicting the future, have been a hobby of mine for a while (as readers of this blog know. Check out some #NoEstimates posts.). Have you considered why we do the sprint planning that way?

A long time ago, in the days before agile, we had problems of trust. We were missing deadlines left and right (maybe that wasn’t only long ago…). We would plan for five year projects. Results were very bad for business.

The business people never understood why developers (and testers, and any part of the product development team), were delivering late. And why they delivered the “wrong” software. They wanted predictability, but never got it. The development team didn’t understand why the business people always change their mind, and then complain that the dev team never met deadlines or budget.

The blame, of course, wasn’t with either side, it was with reality. The longer a project was, more uncertainty poured in, things had to change, new unknowns became apparent, the unforeseen revealed itself. You get the picture.

Developers struggled with unplanned problems. Business people needed to adjust their requirements. Both sides try to maintain course, while dealing with uncertainty. As in many cases, the trust issues were not the core problems, merely the symptoms.

Scrum, and other agile methodologies tried to disarm the trust bomb, by cutting the main wire. In fact, it planned to harness the power of trust for the forces of good.

Introducing a sprint (a lousy word to begin with) or iteration, a short time box, does that, as long as everyone plays by the rules.

  1. Within the sprint, the business people promise not to change their mind. Requirements are stable, and the team can work on them without distractions.
  2. The stories are prioritized so work on them is in order of importance, visible to both the team and the “customer”.
  3. The developers promise to deliver the committed stories as working software. Really working, tested, not “on my machine”.
  4. The planning ceremonies brings both sides to the table, where the developers can give the business people the predictability they always wanted, at least until the end of the sprint.
  5. Because the sprint is a lot shorter than a multi-year project, planning is shorter and more accurate. (Read: There’s not much we can mess up in a single sprint).
  6. At the end of the sprint, in a regular cadence, the business gets to see actual progress by the team. And if they see something they don’t like, they can change their minds and do something about it in the next sprint. (Read: if they messed up the sprint, it wasn’t a big loss).

If everything works, everyone gets what they wanted: The business people get to see actual delivery, predictability of delivery cadence and visibility into the quality of the product. The developers get to work on what they understand, and not on ephemeral requirements. Their estimations are a lot more accurate, and are usually achievable. For everyone, it’s a framework that delivers consistently, effectively and in a more efficient manner than before.

And if everything works, we get a bonus: Trust between both sides rises. And with trust, we can do all kinds of stuff we were afraid to do before. With trust, we can experiment. For example, the business people can let the team suggest and implement features. The business people don’t need to spell everything for the team. They can rest assure that what they get actually works. And both sides can reduce the time spent on planning, and actually working.

Nice things to have indeed. But there’s a catch, of course. The rules have to be obeyed fully.

  1. “Working software” is actually working. Tested, demo-able and ship-able.
  2. No changes within the sprint.
  3. Availability of knowledge (usually product answers) and visibility of status.

When any one of these things break, the framework collapses. Consistent delivery, predictability, and trust is not going to be achieved. It’s very easy to disrupt the framework. But you already know that.

Agility is not about sticking to ceremonies, and scrum is anti-agile in that sense. But, the reasons we plan like that is to achieve that trust and delivery cadence. If your teams have already achieved that, there’s not much sense in adapting scrum planning.If however you decide to do that, make sure you’re adapting it for the right reasons.

So if you’re doing it wrong, it’s fixing time.

We’ll continue with planning wrongness next time. God knows there’s plenty of it.




8 comments on “You’re Doing It Wrong: Iteration Planning”

  1. Henrik Reply


    We’ve worked with Scrum for years. The thing is that not every capability is possible to build in one single sprint/iteration. Thus, the question only transforms into: “How many sprints/iteration will it be?” and we’ve basically haven’t solved anything. Or at least, the concerns you raise in this post remains.

    • Gil Zilberfeld Reply

      Thanks Henrik!

      One of the often problematic skills to acquire by a team is the ability to slice down capabilities that are deliverable.
      While it’s often possible to add capabilities within the sprint, they seem so minor in value (to both team and product), teams just forgo the decision to deliver working very small stories, and instead decide on the architecture split, which unfortunately invites more complexity, bigger integrations and larger risks.

      The small “invaluable” story delivered, reminds me of the smallest thing that works in TDD. Many times it seems too stupid and not valuable. It does play a big roll in acquiring the skill in both cases, though.

      • Henrik Reply

        I agree. Finding small valuable stuff is an important skill. But it’s not a dichotomy. E.g. I don’t consider myself done just because I’ve written my first TDD test. There’s a “threshold” somewhere. The same goes for both business capabilities. Small things are valuable, but idea matters as well.

        • Gil Zilberfeld Reply

          Starting small of course means you’re not done yet. I think that people won’t let themselves set the threshold too low, because it’s not achieving enough.
          Considering the big picture, is how that small thing fits into it. If it’s too small (you can’t see it almost), it’s considered not valuable enough. Where the actual value is not just in delivering it, but also in what you learn working on it, and apply that knowledge to the next steps.
          Value is quite an illusive thing.

          • Henrik

            I completely agree. There’s almost always something smaller that you realize you could’ve delivered once you’re done.

    • R. Michael Rogers Reply

      Troy Magennis and company (Focused Objective) have a set of tools to help forecast various bits of software using Monte Carlo simulations. They have an Excel spreadsheet that directly addresses your case (How long will it take to develop this feature?). Take a look at this page: — the instructions are pretty straightforward.

      I believe the approach assumes “similar sizing” for your User Stories and that you’ve recorded your historical throughput.

      Let me know if you find it useful!

  2. CG Reply

    When do the stories get written? Who does this? Are they on the sprint team? Everywhere I have been, this eventually gets left to the team, and usually a leading developer. Now that developer isn’t working anymore, but preparing stories. They work feverishly to “stay ahead” of the team, and the depth around the stories gets long. Why? Product, QA, Dev, and the senior management don’t understand what you are spending time on unless you are very thorough.

    When do the stories get prioritized? Is that left to the team? A member of the team? When do you have time for this when you are trying to finish an iteration?

    When you get to the end of the iteration, you are supposedly done with your commitments. Some teams even have a ceremony at the beginning of an iteration to say “We all commit to these stories”. I guess that is supposed to be some blood oath that you will work overtime if you have to in order to finish… but

    The team has already tried making stories smaller… to the point of being insignificantly small… and the point that it takes about 6 iterations to get anything that resembles a change into the product. So now it takes 12 weeks to deliver anything, even very small things and still…

    Every iteration, the team retrospective is “we need to make the stories smaller”. They’ve gotten small enough to be changing one line of code, and the change is already pre-vetted. The team is trying to protect itself because every iteration they were saying “none of our stories are done”.

    And yet… sometimes the way you think something might go doesn’t work out. You run into the brick wall part way through the sprint. The software actually can not do what you want, due to some other blocking issue. It blows up the sprint. No one really knows what to do. Sometimes, managers say “we have to meet our commitment”. Other times they say “yeah i guess we just remove this story” and so velocity drops, and the business is discouraged because they start running numbers like “We are spending $140,000 per story point”.

    I haven’t mentioned the part where sprint planning sessions last 5 to 8 hours and take the entire team offline. By the time the stories are presented and everyone is brought up to speed on what is to be done, it takes about an hour per story.

    I have been dealing with this as a member of various scrum teams for about 4 years now, and each of them has headed to the same place. I really haven’t been able to figure out how to deal with it. I’m sure the answer is “your org is doing it wrong”, but these processes were all decided upon and every team is supposed to report to them.

    • Gil Zilberfeld Reply

      Lots of good questions!

      Writing stories: I see more product managers taking up a lot of time writing them, which leaves them away from product management. Thus, we get product owners as a position, rather than a role. I think I’ll post about this in the future.

      Prioritization is a skill. Actually a set of skills. As a (scrum) rule, it’s done by the PO, with feedback from the team. I see a lot of prioritization as a time consuming activity, more than it should be, and I think that’s because people don’t practice it enough to master. Mind you, it needs to be done, otherwise, you’ll be working on the less important things first, and missing out on value.

      Commitment. It has a special place in the “You’re doing it wrong” series. Velocity too.

      Slicing is a technique that, well, that’s another post in the series. In a word, just slicing without recognizing the value that depends on the maturity of the level can be dangerous (or another electric knife analogy).

      I feel your pain. And you already know you (or your org) are doing it wrong. Although like I said today to someone: I don’t rate you on the scrum scale. Being a 10 on it doesn’t guarantee success, and there are people with 0 who are doing great. But they understand the values behind the practices, and I find these people to be very rare. Unfortunately.

Leave A Reply

Your email address will not be published. Required fields are marked *