Following on from my previous post which gave a brief overview of Agile Development, it’s now time to look at the Backlog in more detail. In particular I want to focus on the early part of the process where the development team builds the Agile Backlog from the items on the Product Roadmap.
The product back log is owned and managed by the Product Owner. It’s purpose is to bring the roadmap into the domain of the developers and hold enough detail that each item it contains can be worked on and delivered within the span of a single sprint.
Note — the shorter the sprint length, the smaller the stories must be.
Roadmap Features can be huge, not very well understood, span multiple teams and require different disciplines to deliver them. In short, a single Agile team cannot reasonably be expected to deliver them as they stand. They need to be broken down into smaller entities and this is where the notion of Epics and Stories come in. They are very similar to their namesakes in the film industry and in this context, features consist of epics which consist of stories.
The story is the smallest unit of work. To be scheduled into a sprint, the story must be small enough for the team to complete and deliver it within the span of single sprint period. If this isn’t possible the story is too large and will need to be broken down further.
Epics can be though of as very large stories although they are not worked on directly. They must only span a single sprint team and often contain multiple stories. Ideally an Epic should be fully delivered in the course of a single release.
Epics are very useful in the release planning phase when defining and agreeing scope.
List of Images
Figure 1. THORN, 2018 Agile Backlog
Figure 2. THORN, 2018 Agile Backlog
Figure 3. THORN, 2020 Features, Epics and Stories
Figure 4. THORN, 2020 Features, Epics and Stories
