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 (work items) 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 Types 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 An agile process has defined work items that are available during the process and it has defined relationships between the work items. For example, 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. Work items are always stored in a backlog and are discussed in planning meetings. During daily standup, every team member answers the same questions about the work items to which they have been assigned.
Backlogs An agile process has a common backlog, from which specific items are associated to release backlogs and to sprint backlogs. In general, as the work type gets smaller, two things should happen: the size of the work items associated with it should get smaller and the amount of information contained within the work items (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 work types (product, release, sprint, and team), work items (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 organization's that use agile, their approach to the details is rarely the same. There will be different names for work items, work types, and backlogs. There will be different relationships and orders of work types. There will be different lengths of each phase within the lifecycle. There will be different approaches for how work items are 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 work types, work items, and backlogs are (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 the way an organization chooses to manage the work types, work items, and backlogs that make up the framework of your organization's agile process.

For more information, see the following topics: