Establish Backlog (APS02)

Generate Themes (APS02.1)

Description	Once the vision is established the team can decompose that statement into a few more specific themes (or goals) that the system will be expected to satisfy. These are usually at the “idea” level or “goal” level and can be used decompose the vision further if need be into more detail. They can also be used to spur innovation by giving people a starting point of ideas to decompose
Who is Involved	Business Stakeholders Product Owner (Primary) Agile Coach(if needed) Scrum Master
Mechanism	Backlog Grooming Meeting(s)
Frequency	At least once at the beginning of a project, periodically as needed in later backlog grooming if business needs/priorities change
Outcomes	A few theme statements of a similar format to the vision which all stakeholders agree is a complete listing of their hopes for the solutions capabilities and uses
Guidelines	Don’t worry too much about getting the level of detail “perfect” for themes. Themes can easily be converted to epics later if they are detailed enough, or further broken down, if they are too nebulous If it is conceptually easier for the team to start with epics and extrapolate the themes from those, that is acceptable as well Your backlog must capture the input from external stakeholders as well, such as Security, Enterprise Architecture, Legal, User Experience, etc.

Generate Epics (APS02.2)

Description	Once the themes are identified they can be broken into epics, which are large units of scope that start to describe what, specifically, the solution must do or enable. These are the first “concrete chunks” of a solution, and are commonly expressed at the level of feature sets, features, procedures/processes, and the like. These are the basis of the “working solution” desire which is the goal of each sprint.
Who is Involved	Business Stakeholders Product Owner (primary) Agile Coach(if needed) Scrum Master
Mechanism	Backlog Grooming Meeting(s)
Frequency	As frequently as needed.
Outcomes	A more concrete set of solution features, integration points, processes, and other functioning units.
Guidelines	At the start of the project, plan to spend a couple hours each week to define and refine the epics. Each epic should be modular in that a particular epic/feature could be built, tested, and verified on its own. NOTE: This does NOT mean an Epic cannot have dependencies on other epics being completed first. For example, in a theoretical online sales system, an order-generating module might not be built before a cart module is completed. However, the cart could theoretically be built and accepted on its own, and then after that fact the order-generator could be built and tested. Again, don’t worry too much about getting the level of detail exactly right for an epic. A good epic is simply an easy-to-understand functioning unit, which will then be broken down further into more detail as user stories and acceptance criteria. As a guideline, you can use the “Business Requirements Report” as a template to help you determine all areas your backlog should cover. This is particularly important for auxiliary teams you may work with throughout your project. Make sure all applicable sections of that document are handled as epics in your backlog, with user stories and acceptance criteria accounting for the individual line items. Business rules & use cases Reports & reporting requirements Performance, availability, & capacity Planned interfaces Security requirements

Generate User Stories (APS02.3)

Description	Using epics as a base point, the team then analyzes each epic individually (starting with the highest-priority or highest-value) and determines how to define milestones for the epic in terms of solution components, features, modules, pages, or other types of work items. User stories can be as big or as small as needed for the team. They can be as large as whole modules (i.e. think of a check-out module), individual pages/screens (i.e. a confirmation pop-up), or could even be specific aspects of a single page elements (i.e. database calls made by a “Buy Now” button), all depending on the team capacity and length of the sprints. The appropriate “Size” of a story will become evident later as the team as a whole starts planning work for individual user stories.
Who is Involved	Product Owner (primary) Agile Coach (if needed) Scrum Master Scrum Team/Technical Resources
Mechanism	Backlog Grooming Meeting(s)
Frequency	As frequently as needed to establish enough user stories to “fill up” the first several development sprints for the project. Depending on the availability of the Product Owner and team some teams do a few long meetings (2-4 hours), other teams do daily 1-hour meetings until the team is comfortable they have enough user stories to begin working.
Outcomes	The first iteration of the “Solution” backlog will be populated with user stories.
Guidelines	At the user story Level, the more detail that is known the better, and all known requirements can be documented as “Acceptance criteria”. Acceptance criteria will be further refined and confirmed in Sprint 0 A user story should be: Independent – The story does not overlap with other stories in the backlog and sprint Negotiable – The story “Definition of Done” is ready pre-sprint, but can be re-scoped as the sprint progresses with team consensus Valuable – Product Owner is willing to accept the story as a sign of progress towards their larger goal of adding business value Estimable – The story can be estimated with story points and task roll-ups Small – Story can be completed in one sprint Testable – The Product Owner and team understand how to test the story to confirm it meets “Definition of Done” Each user story should have a well-defined, clear “Definition of Done” and Acceptance criteria, so that anyone who reads it, within or outside the team, instantly knows how to tell when it is finished As a guideline, you can use the “Business Requirements Report” as a template to help you define areas your backlog should cover. This is particularly important for auxiliary teams you may work with throughout your project. Make sure all applicable sections of that document are handled as epics in your backlog, with user stories and acceptance criteria accounting for the individual line items Business rules & use cases Reports & reporting requirements Performance, availability, & capacity Planned interfaces Security requirements

Adaptive Planning Illustration for Initial Backlog Creation

It is acceptable for requirements to be at a high-level at project inception. At this early stage, it is more important to define a full list of the desired scope at the theme, epic, and feature level than to get caught up in detailed analysis for detailed requirements. For initial backlog generation, it is acceptable for the Product Owner to focus on exhausting their notion of features and scope, prioritizing that list, and then refining that down over time into user stories and acceptance criteria

This prevents so-called “Analysis Paralysis”, whereby a project gets stuck spending too much time thinking about detailed requirements for the full solution and thus sacrifices time that could be spent building the highest-priority parts of the solution.

NOTE: That said, IF DETAILED REQUIREMENTS ARE KNOWN AND CLEAR at this stage, they can (and should) still be captured, as that will make user story and acceptance criteria generation easier later in the process. The premise here is that if the detailed requirements are unclear at this time, don’t worry about them and focus more on the high-level requirement for the whole solution, as in Agile there is time later on to refine