We already understand what a story is in Scrum and how to work stories using INVEST. Let’s now take a look at how to classify these stories.
As we have seen, stories are the requirements of the project / product being worked on. Stories are kept in Product Backlog and sorted by work priority. So it is natural to have several stories to work on our Backlog.
Considering that products are created or developed in collaboration with the entire team, as well as external agents such as stakeholders, product managers, etc., everyone should be encouraged to make their contributions as stories. However, only the
PO can include stories in the Product Backlog as it is his responsibility for the venture’s ROI. In ScrumHalf, for example, any project participant can write and suggest a story, but only the PO can accept stories. That is, proposed stories have their own repository where they can be evaluated by the PO and accepted into the Product Backlog if they wish.
Both the proponent of a story and the PO can classify the story to make it easier to understand in its context. In the case of ScrumHalf, stories can be classified as Feature, Epic, Bug or Technical. Each of the types has a specific icon, which is displayed in the Product Backlog to facilitate the team’s work.
Features are the default stories of a project. That is, it results in some new functionality or feature that is clearly perceived as value by the customer. In addition, they are already at the correct level of abstraction for DevTeam to work with. Regardless of their size, they cater to INVEST and when Ready can be included in a Sprint.
Epics are stories that are still very large, at a very high level of abstraction or in need of greater detail. That is, to be worked on, they will still have to be better detailed and, in most cases, partitioned into smaller stories that meet the INVEST.
Bugs, as its name implies, are problems encountered in the work being done that need to be fixed in order for the product to behave properly. These are corrections that the team needs to make.
Technical are generally associated with non-functional requirements of a project, ie activities to be done that do not directly translate to user or customer value, such as activities related to the project / product infrastructure or technology used, e.g. In software projects it is common to be classified as technical, stories related to project and team infrastructure, refactoring, technology changes and spikes. Some teams also classify bugs as technical stories. At ScrumHalf we prefer to separate, as we understand that Bugs should be highlighted in order to deserve special attention from the Team as a whole.
And your team? Already work sorting stories? How do you differentiate different types visually? What types of stories are considered Techniques? Tell us there in the comments.
Good scrum. 🙂
