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 that is 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 width of the box represents the number of days it would take for 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 more than 15 days 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 in the event that you are producing 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 at the same time, we don’t typically plan for this. Instead, we assume that only one person is able to implement a requirement at a time. This provides a more conservative estimate of production but prevents issues that might arise should one member of the group working on one requirement is unable to do the work for any number of reasons.
• To determine how long (total days) it might take your team to complete the project, add up the time estimates for each of the requirements. Divide the result by the number of team members working on implementation.
• To determine the number of iterations it might take to complete the project, divide the result you determined in the previous bullet by the length (in days) of the iteration.
• Since dependencies might affect when we implement each of the requirements, the estimates from the previous two bullets are probably on the low end. That is, it will likely take longer to implement because dependencies will cause gaps (as shown on the previous page) and because we haven’t considered how productive our team actually is. But we’ll discuss that in the next chapter.

Review Questions