Do you assign severity levels to PBIs?
Updated by Seth Daily [SSW] 10 months ago. See history
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.
Categories
Need help?
SSW Consulting has over 30 years of experience developing awesome software solutions.