Unpacking the problem
A product backlog is one of the most important artefacts when building software. It is the what, why, how and when of feature development.
Since requirements can be expressed in several ways, there are a variety of strategies for capturing and understanding them. Whether it happens verbally during a meeting or through a brainstorming session on a whiteboard; it is vital that all requirements are recorded in a backlog.
A commonly used method for recording these requirements is to understand a user’s intent through epics and user stories. Beyond epics and user stories, other ticket types can arise such as tasks, defects and spikes both within scoping and active development. It’s also imperative to capture the acceptance criteria for each user story to ensure that the team and product owner have a shared understanding of what makes each story complete. These issue types can typically be defined as the following:
Epic: A high-level theme or feature that is used to categorise related stories, tasks and defects.
Story: A fine-grained requirement, written from a user’s perspective, that is small enough that it can be logically estimated and built within a short period.
Task: A work item that isn’t written from a user’s perspective and is instead a technical item required to achieve the applications stories.
Defect: A work item typically related to an epic, that has arisen as a result of application testing, which can be a technical bug in the application or a usability issue.
Spike: Typically, a time-boxed work item with a learning goal associated with de-risking some technology or concept.
Once the product backlog is complete and covers all functionality shown in the prototype and database model, the scoping team is ready to estimate the build.