How Long Are Your Iterations? Part 1

I spoke with a Scrum Master the other day. He was concerned that the team didn't finish their work in one 2-week iteration. He was thinking of making the iterations three weeks.

I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported defects post-iteration?

He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I'll address later.)

Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours.

Staggered_dev_testingThe developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don't finish.

I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing.

“Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.”

I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing.

“Oooh.” He hadn't realized that.

He also had not realized that they are taking too much work (here, work in progress, WIP). The fact that they need more time to discuss stories in their planning meeting? A lot of WIP. The fact that the developers finish first? That creates WIP for the testers.

Sequential work makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag time between the time the development is done and the testing is done?

The next post will be about when you have a longer duration based on interdependencies. See How Long Are Your Iterations, Part 2.

2 Replies to “How Long Are Your Iterations? Part 1”

  1. Hi Johanna, very nice. I had a similar problem recently – I worked with a team that only recently adopted some of agile practices, namely short iterations. However, they were not doing testing within their iterations, the testing was done only after them. I also tried to convince them that a) their idea of “iterations” is wrong and that they should include testing directly inside iterations and b) their approach is flawed and causes only multitasking, as in each iterations, instead of working on new stuff, the developers would be doing bugfixing from the testing.

    In our company (that is not the team I was referring to above, of course :)) we have 3 week iterations, because we simply cannot manage to get something “done” in 1 or 2 weeks. I have been trying to shorten our iterations for quite some time, but I have come to the conclusion that doing so will bring us no value, because the smaller stories would no longer be valuable (so goodbye early customer feedback). Thinking about it more, I have come to the theory that iteration (and story) size is dependent on many factors, main of them might be size and complexity of the product, the technology used (legacy technology makes short iterations really hard), complexity of the environment (both technical and organizational), number and type of integrations the product has, how much the business is regulated and perhaps some others. So, in the end, I have come to the conclusion that things are not as simple as we may think and there are no one-fits-all solutions – we should always use our experience as a guide, but also our understanding and judgment to find the best solution for the given situation, right?

    1. HI Tomas, I wonder if you need the three-week iteration because of “curlicue” stories. That’s my next post. Look for it tomorrow.

      I do agree with you—there are useful practices. There is no best solution. All of our solutions are context-dependent. That’s why thinking is so important!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.