Every element of a project method has a reason. If you know the reason, you know when to apply or use this method component. To explain this, I created a small sample using Scrum, and I turn to some global observations about it. I use the word global as I will not go into every little detail, but use the information that is available on the fabulous site ControlChaos.com.

Taken from that site:

Scrums Three Tools:

1. Backlog: Overall, by product line, by product, and by system an organization identifies all outstanding work and prioritizes it. This prioritized backlog list changes continuously and is updated and reprioritized continuously.

2. Sprints: Work increments where a team works on completing an identified, self-contained group of prioritized work. During the sprint, the work is not changed from outside the sprint, although as work occurs in the sprint, additional work may be uncovered.

3. Scrums: Daily meetings where a Sprint team meets to identify what work was just done, what work will be done next, and what is impeding work.

Here are some of my observations to add to the information given above:

1. Backlog: This list is the general planning tool. This is needed to provide feedback to the team members on what should be done, feedback to the users on what will be happening with their requirements, and feedback to management on progress and need for interventions/decisions. As only the items are planned for the current and/or next sprint (iteration), it can cause a problem with management that wants to have some statement about the long-term planning and cost. On the other hand, the underlying idea behind Scrum is that with unknown requirements (see 2. Sprints), every statement about the long term is almost useless. Only based upon the real speed of the team are time frames determined, and only for the foreseeable future. So the question is: Can you convince management that it is better to stay in reality and get involved in the process, or do they want to work with statements based upon feelings and hunches and have a false sense of security (some people prefer the latter)?

2. Sprints: Scrum uses an incremental approach to provide early feedback of some end result. The underlying risk that is covered here is uncertainties in requirements. By providing feedback in a working version as early as possible, this system allows the end users to view if the requirements are properly addressed. Also, a close involvement of end users within the Scrum team covers this risk. However, to be able to determine if the requirements are properly addressed, users will have to look to at least some version of the system that satisfies a certain business goal in its whole. As certain sets of requirements are dependent on each other, a real opinion can only be formed when a major part of the requirements are addressed.

If you look further in the sprint definition, you will find that it has to satisfy a sprint goal, which should be some business goal. So Scrum doesnt promote iterations just for the sake of iterations. The idea is to provide feedback, and if that is not possible in a good way, the increments dont make any sense.

3. Scrums: The Daily Scrums last no more than fifteen minutes. During the meeting, everyone on the team answers three questions:

1. What have you done since the last Daily Scrum?
2. What will you do between now and the next Daily Scrum?
3. Whats getting in the way of your doing your work?

This is to provide daily feedback to each other (including management) on the current state of the work and to address issues that need to be taken care of. Actually, these are just rules for an efficient meeting. Other methods also provide this, but the aggressiveness of the name Scrum has strong appeal.

From this short sample you can see that feedback on product and process are used to either reduce risks or satisfy the needs of stakeholders. You can also use the backlog technique in approaches other than Scrum. Heck, priority lists of requirements and risks can be found in other methods also. However, calling it a backlog is an in-your-face name, calling it exactly what it is. There are more methods that take an incremental or iterative approach, but always remember what it is you are trying to address, why you go incremental. Without having the sprint goal, the sprints would be useless.