Now that we’ve finally developed a set of requirements that formally define the problem we are trying to solve, we can begin building our plan to turn it into a reality. This includes developing a formal production timeline composed of iterations and milestones.

Since we spent so much time developing our requirements in the previous chapter, it should come as no surprise that a requirement is one thing that the system does. However, the terms iterations, milestones, and timelines might be new.

Iterations, Timelines & Milestones

Iterations – an iteration is a set of requirements that are completed in a short amount of time. The length of an iteration may vary depending on the company for which you work and the complexity of the problem but four weeks (20 working days, or approximately one month) is typical.

Milestones – are a major release of the software. Milestones are connected to software versioning.

Timelines – a timeline is a complete set of iterations.

Our goal is to arrange the requirements into a series of activities that will allow us to implement our solution as efficiently as possible. If you are the only developer, this would amount to scheduling the requirements one after another, with dependencies addressed ahead of the requirements that depend on them.

An example timeline (with the first milestone completed after the second iteration) is outlined below. Note: each coloured box represents one requirement. The box width represents the days it would take one person to fully implement the requirement.

However, it is very unlikely that you will be the only developer involved with implementing the solution that was planned. Instead, it’s typical that you will have a team of people who will contribute to implementation.

In this case, assigning requirements becomes slightly more involved, because implementation can take place simultaneously. This means that care must be taken to ensure that dependencies are met. It also means that there may end up being several team members who are unable to implement anything related to the current project – so gaps may appear in the timeline.

Before we learn how to build our timelines, it’s important to point out a few things:

• If a requirement takes 15 days or more to implement, you should probably break it down into smaller chunks.
• Each iteration should end with an update and potential demo to the client/user so that they can stay connected to the project. This is also a good time to re-evaluate the full timeline, especially if you are faster or slower than expected. Any changes to the timeline require consultation with the client/user.
• While there will be cases where several people could feasibly work on the same requirement simultaneously, we don’t plan for this. Instead, we assume one person can implement a requirement at a time. This provides a more conservative estimate of production but prevents issues that might arise if someone can’t complete the work.
• Add requirement time estimates (in days) and divide by the number of team members to estimate project duration.
• To estimate the number of iterations to complete the project, divide the result you determined in the previous bullet by the length (in days) of an iteration.
• Since dependencies might affect when we implement certain requirements, the estimates from the previous two bullets are probably on the low end. It will likely take longer to implement because dependencies will cause gaps (as shown previously). We also haven’t considered the team’s productivity level. But we’ll discuss that in the next chapter.

Review Questions