concept iteration in category software development

This is an excerpt from Manning's book Kanban in Action. Login to get full access to this book.

“Yes, that is correct,” Marcus responded. “In this first iteration at least. We’ll see changes to that soon, in the iterations to follow.”

An iteration typically starts with some sort of planning or assessment of what you’re getting ready to do; you do it, and then you’re done—preferably you end by looking back on what you’ve done during the last iteration and seeing if you can improve. The cadence for the sprint is, for example, two weeks, and a new “heartbeat” in your process is started when the next iteration begins.

As you can see, iterations are like timeboxed, small projects with a clear start and goal. As an example, you can see an iteration in action on a board like this:

In the first picture, the team has lined up all their work for the next iteration in the Todo column. In the mid-iteration picture, some work items are being worked on, others are done, and there’s one that hasn’t been started yet. At the end of the iteration, hopefully all of the work items have been moved into the Done column. The board is reset, and the team starts over by planning for the next iteration.

This is an excerpt from Manning's book Specification by Example: How Successful Teams Deliver the Right Software. Login to get full access to this book.

Many teams have also discovered that using Specification by Example to make requirements more precise at the start of a development cycle makes it easier to manage product backlogs. For example, being able to spot stories that are too vague or have too many gaps in required functionality early on prevents problems later. Without Specification by Example, teams often discover problems in the middle of an iteration, which interrupts the flow and requires time-consuming renegotiations—in larger companies, stakeholders who decide on the scope are often not readily available.

Specification by Example helps teams establish a collaborative specification process that lowers problems in the middle of an iteration. Additionally, Specification by Example fits into short iterations and doesn’t require months of writing long documents.

In this chapter, we’ll look at how to begin changing process and team culture so you can implement Specification by Example. We’ll review three team case studies that represent different ways to integrate collaboration on specifications into iterations and flow development. Finally, I present useful ideas for fitting this process into development environments that require sign-off and traceability on requirements.

Get sign-off on exported living documentation: When: Signing off - iteration by iteration

This is an excerpt from Manning's book Becoming Agile ...in an imperfect world. Login to get full access to this book.

When an iteration begins, the specific plan for the iteration is revisited. The team adds any new user stories and tasks that have been discovered since the overall release was outlined.

XP integrates customer testing into the development iteration. The customer is asked to identify the acceptance tests, and the team works to automate these tests so they can be run throughout the iteration.

How do we adapt at the end of an iteration? We’ll cover this question in section 20.3. Acme Media will demonstrate a solid process for gathering feedback at the end of an iteration and recalibrating the project based on the customer response.

Figure 20.1. Adapting occurs throughout an iteration and following an iteration review by the customer.

20.8.3. Features originally slated for iteration 2

Acme outlined an overall release plan before they began working on the features. The original plan called for two iterations, with the minimal feature set needed to go live in iteration 1 and secondary priority features in iteration 2. You can see features originally slated for iteration 2 in table 20.2.

Table 20.2. The initial plan for iteration 2, before the discoveries from iteration 1

Feature name (ability to)	Story points
Purchase an item immediately	2
Flag problem postings	2
Contact the seller	3
Create alerts for item type	3
Receive help online	5
Record seller feedback	5
View seller information	2
Total	22

This is an excerpt from Manning's book Test Driven: Practical TDD and Acceptance TDD for Java Developers. Login to get full access to this book.

Too many projects have pushed back their deadline again and again, eventually getting canceled, without delivering a single line of working code. By building your product in small increments, iteration by iteration, you don’t have to worry about not making the deadline because you have a working (albeit not feature-complete) system starting from the first iteration. Similarly, too many projects have delivered buggy code as a result of a last-minute rush of getting it together for the deadline.

Notice how the stories get completed almost from the beginning of the iteration? That’s the secret ingredient that acceptance TDD packs to provide indication of real progress. Our two imaginary developers (or pairs of developers and/ or testers, if we’re pair programming) start working on the next-highest priority story as soon as they’re done with their current story. The developers don’t begin working on a new story before the current story is done. Thus, there are always two user stories getting worked on, and functionality gets completed throughout the iteration.

Figure 9.10. Putting acceptance test-driven development on a time line

So, if the iteration doesn’t include writing the user stories, where are they coming from? As you may know if you’re familiar with agile methods, there is usually some kind of a planning meeting in the beginning of the iteration where the customer decides which stories get implemented in that iteration and which stories are left in the stack for the future. Because we’re scheduling the stories in that meeting, clearly we’ll have to have those stories written before the meeting, no?

Although an iteration should ideally be an autonomous, closed system that includes everything necessary to meet the iteration’s goal, it is often necessary—and useful—to prepare for the next iteration during the previous one by allocating some amount of time for pre-iteration planning activities.^[5] Otherwise, we’d have long-lasting planning meetings, and you’re probably not any more a friend of long-lasting meetings than I am.

⁵ Suggestions regarding the time we should allocate for this continuous planning range from 10–15% of the team’s total time available during the iteration. As usual, it’s good to start with something that has worked for others and, once we’ve got some experience doing things that way, begin zeroing in on a number that seems to work best in our particular context.