Overview

The ideal Agile process is simple and repeatable. It's scope is high-level, but with specific goals. Scope is defined in a product roadmap. Goals are the features that add business value to the product. The process relies on similar patterns across levels, but with a greater focus on detail as a team gets closer to doing actual work. This does not mean that making that process work is easy. In fact, making an Agile process work can be hard, but the steps within the process itself are simple.

Every Agile process relies on basic framework:

Work Type An Agile process has defined relationships between the types of work done during each stage in the process. For example, a project contains one or more releases, a release contains one or more sprints, and every working day in a sprint contains a daily standup.
Work Items A work item is an epic, story, or a task. An epic can contain one or more stories, a story can contain one or more tasks. A work item is always stored in a backlog and should be discussed in planning meetings. During daily standup, every team member answers the same questions about any work item to which they have been assigned.
Backlogs An Agile process has a common backlog, from which any specific work item is associated to a release backlog or to a sprint backlog. In general, as the work type gets smaller, two things should happen: the size of a work item that is associated with it should get smaller and the amount of information contained within that work item (description, acceptance criteria, technical notes, story sizing estimates, and so on) should get larger.
Teams Every Agile process is highly dependent on the quality of its team members. Product owners. Scrum masters. And individual team members.

The relative simplicity of an Agile process helps your organization move past the traditional project management focus on process and helps to put more emphasis on the interactions between team members towards deliverables and towards customer's needs and requests. After you have completed each step in the Agile process (such as completing a sprint, release, or product), your team should have a retrospective, discussing what went well and identifying areas of improvement.

The following diagram shows the relationships between all of the elements in the Agile lifecycle, including a work type (product, release, sprint, and team), any work item types (epic, story, task, impediment, and defect), planning (product, release, and sprint), and backlogs (product, release, sprint, and team).

Even though the basic structure of Agile is used by most organizations that use Agile, their approach to the details is rarely the same. There will be different names for a work item, work type, or backlog. There will be different relationships and orders of any work type. There will be different lengths of each phase within the lifecycle. There will be different approaches for how a work item is managed and defined in the backlog.

In order to make Agile work well in your organization, you need to constantly refine it and sometimes re-define it. The relationships of the a work type, a work item, and a backlog is (in part) defined by your organization's work breakdown structure and (in part) defined by how your organization chooses to measure business value. In other words, the success of any Agile process has as much to do with an organization's commitment to Agile as it does to how an organization chooses the actual steps within the process.

For more information, see the following topics: