Correct Work Item Hierarchy in Azure Dev Ops

Question

We are currently switching from our so-and-so somewhat agile management approach to Scrum and I as a developer have a hard time understanding, what comes first in Azure DevOps as the top level item.

From my understanding the road map of the product is the product backlog, so everything that should be done, should get put in here first as a "Product Backlog Item"

The PO then prioritizes each product backlog item (PBI) and in the Sprint Planning we decide if this is a Feature (one Sprint duration) or an Epic (multiple sprints), which in turn then get concrete tasks assigned to it, that need to be done.

In a Visual representation this would look like this:

PBI
|
----Feature
    |
    ----Task 1
    ----Task N
|
----Epic
    |
    ----Feature 1
    ----Feature N
        |
        Task 1 - N

In our organization this is currently somewhat turned around, so that the Feature / Epic comes first and those have PBIs assigned to it and those PBIs have the tasks:

Feature
|
----PBI
    |
    ---- Task 1 - N
Epic
|
----Feature
    |
    ----PBI 1
        |
        Task 1 - N

From how I understand, the PO can or should not create Features or Epics, only PBIs, and we as the development team, with our technical knowledge about the product then estimate then decide if it will be a feature or epic. But that would mean, that we would need to create parents of that PBI and this is confusing me.

Which of the 2 is the correct (or more correct approach) and why? I am aware, that I might completely misunderstand the logic behind this and both approaches might be wrong.

Answer 1

The Epic is just a bigger Feature which itself might require smaller features (multiple User Stories) to get Done.

It goes like this:

When an item is first added to the Product Backlog it is unrefined, meaning somebody just added it there and it needs to be discussed during the Product Backlog Refinement meeting. This meeting anticipates what will be worked on in the near future.

The Product Owner sees the PBI and gives it high priority, thus including it in the PBR meeting. Based on discussions with the Development Team, this item is estimated and probably broken down into smaller items.

The initial estimation might be something like 20-30-50SP and estimations by each Development Team member might be all over the place. It's normal because it's too big, too broad and it's not (yet) clear what exactly is needed to get it Done.

Remember: only the PBIs which can be delivered within one Sprint should be selected during Sprint Planning into the Sprint Backlog.

If the item is too large, it needs to be broken down into smaller items before the Development Team works on it. An Epic is broken down into Features and further into User Stories, which are just smaller features.

Answer 2

PBIs should not be treated as something different from epics or features. Epics, features, requirements, and tasks can all be product backlog items.

In Azure Devops the hierarchy is as below:

Epic
|_____Feature
         |______Requirement
                      |________Task

Epic, being the top-level requirement.

The goal is to break down anything that's bigger than a task into one or more deliverable tasks. Doing this helps the team to plan the deliverables for the sprint during their sprint planning as Epics, features or requirements might or might not fit into a single sprint. Sizing helps you identify whether the PBI needs to be broken down further. Usually, any PBI that's bigger than 13 story points is split up or broken down further.

Although the PO adds and prioritizes the PBIs, they are broken down with the help of the development team during the Product Backlog Refinement meeting. The aim here is to have enough refined PBIs to plan for the next sprint.

Answer 3

The Scrum Guide does not say anything about the backlog other than there is "items" in it. So consider the following my experience, not the official guide:

The Product Owner should be able to decide whether something is an Epic, a Feature or a User Story. Because it's not about how complex it is or how long it takes, but what it is to the product. There is no hard rule that an Epic has to span multiple sprints. If all it's features' stories can be done in one sprint, that's great. And it does not make it less of an epic.

A user story is basically a users interaction with the product. For example: "As a user I want to select a screen name from the list of online people to start a chat with them".

A feature could be the ability to chat in general: "Users should be able to chat with each other".

An epic might be the ability for users to interact: "The product should have a social component so users can interact".

The decision is a business decision and your PO should be able to decide that from Epic down to User Story.