Do you assign severity levels to PBIs?

Last updated by Chloe Lin [SSW] 8 days ago.See history

As the backlog grows, it becomes increasingly challenging to determine the relative importance of each PBI (Product Backlog Item). Assigning severity levels to each ticket can help address this issue by clearly indicating which tickets have a higher business impact. Severity levels range from 1 (Highest) to 5 (Lowest).

How to Assign Severity Levels

Option #1: Default to Highest Severity (1)

Pros:

  • Ensures that the team is focused on what the Product Owner views as the most critical PBIs

Cons:

  • The team might lose sight of what's genuinely essential, as every PBI is initially treated as high priority
  • Lack of guidance can lead to an unbalanced distribution of PBIs across the severity levels

Option #2: Default to Lowest Severity (5)

Pros:

  • Encourages a balanced view of the backlog, allowing the team to focus on lower-priority items initially

Cons:

  • Not suitable for open-source products, as contributors may be discouraged to see their PBIs assigned the lowest severity

Option #3: Default to Medium Severity (3)

Pros:

  • Provides a balanced starting point for PBIs, allowing the team to focus on a mix of priorities
  • Aligns with a normal distribution, making it easier for the Scrum team to decide which PBIs to tackle in the next sprint

Cons:

  • May require frequent adjustments during Backlog Refinement to accurately reflect the business impact of each PBI

This is often the most practical approach. By aligning with a normal distribution, it allows for a balanced view of the backlog, ensuring that the team is focused on a mix of priorities without neglecting any severity level.

Ideal Distribution of Severity Levels

For an effective distribution of severity levels, consider the following distribution:

  • Severity 1 and 5: 3% of the tickets each
  • Severity 2 and 4: 13% each
  • Severity 3: 68%

This distribution resembles a normal distribution and provides a clear guideline for the team to decide which PBIs to prioritize in the upcoming sprints.

We open source. Powered by GitHub