I define iteration as a repeated, timeboxed cycle of work. First, I mean the general sense. For example, I mean any repetition of a procedure, a process, or a piece of program code. Second, I mean the agile sense. In agile, I call an iteration a timeboxed unit of work. Then, I say the development team implements an increment to the system within that unit. Also, I note that teams often use the word sprint as a synonym for iteration.
Furthermore, I describe short iterations as sprints. Typically, I plan sprints to last between two and four weeks. In addition, I use short iterations to get fast feedback. Consequently, I reduce risk and improve focus. Moreover, I use them to deliver small, testable increments. Specifically, I expect developers to complete backlog items allocated during sprint planning. Therefore, I keep scope stable for the sprint and measure velocity.
However, I also distinguish longer iterations. I call these releases. For example, I use releases to integrate results from multiple teams. In addition, I group several short iterations into one release. Thus, I create a shippable product increment for customers. Meanwhile, I coordinate releases with a roadmap. As a result, I synchronize teams and manage dependencies.
Moreover, I stress cadence. First, I set a regular rhythm for iterations and releases. Then, I keep the rhythm stable. For instance, I hold daily standups for the developers. In addition, I demonstrate progress at the end of each sprint. Consequently, I create a sense of resolution and predictability. Likewise, I align multiple teams to a common cadence when needed.
Also, I explain roles and backlogs. For example, I keep a single product backlog even at scale. In addition, I assign parts of that backlog to sub-teams or area product owners. However, I make sure someone owns requirements. Specifically, I make the product owner responsible for backlog prioritization. Moreover, I require sub-teams to communicate regularly about overlaps, dependencies, and priorities. As a result, I improve integration and reduce conflicts.
Furthermore, I discuss refinement and readiness. First, I refine backlog items before iteration planning. Then, I use refinement meetings to avoid disturbing developers. In addition, I allow up to 10% of developer capacity for refinement. Otherwise, I see a warning sign of poor requirement quality. Also, I define a Definition of Ready (DoR). Specifically, I use the DoR to ensure developers have enough information to complete a backlog item within one iteration. In contrast, I use the Definition of Done (DoD) to confirm that developers completed the work correctly.
Moreover, I encourage automated testing. For example, I use test-driven development (TDD) or executable acceptance tests. In this way, I verify the increment at the end of an iteration. Consequently, I show the product owner that the team delivers what is needed.
Finally, I summarize: iteration means repetition and a controlled, timeboxed step in development. Therefore, I use iterations to deliver value frequently. In addition, I coordinate short and long iterations to handle both team-level work and large-scale integration. Thus, I achieve faster feedback, clearer priorities, and regular delivery.