Let's start with one Story
-----------------------------------------Ram, the marketing manager, is shaking his head. “That’s a high on the severity scale. It’s really bad, guys. You have to make it a high.”
Raj, the development manager, is barely containing his frustration. He replies, “No, Ram. That’s not all that bad. It’s an inconvenience, I agree, but there’s an easy workaround.”
“Inconvenience?” “You call not being able to print an inconvenience? That’s a disaster!”
“Yes, I call not being able to print from one particular type of printer without installing an upgraded driver from the vendor’s website an inconvenience. The user just needs…”
“I know what the user needs,” Ram cut in. “The user needs to be able to print out of the box! You can fix this in our code, right?”
Raj nods, “Yes, but we’d just be working around the vendor’s…”
“Then fix it.” Ram stood over Raj, glaring.
“But it’s a medium and at it's best!” Raj objected. “The user isn’t losing any data, doesn’t have to reboot, isn’t crashing. They just have to update a driver.”
This argument could continue forever. What’s really happening here? Lets talk about this. According to their position and understanding both guys are correct. Now you will think i got mad. Ok let's discuess it.
Priority is Business and Severity is Technical
------------------------------------------------------------
Ram is looking at business priority: “How important is it to the business that we fix the bug?”
Raj is looking at technical severity: “How nasty is the bug from a technical perspective?”
These two questions sometimes arrive at the same answer: a high severity bug is often also high priority, but not always. I know these words looks
bit confusing, but if you give a serious look on, really not. Let's start from basic. I have tried to put the issue on the scale of Severity and Priority level below.
Severity levels:
* Critical(P1): The software will not run
* High(P2): unexpected fatal errors (includes crashes and data corruption)
* Medium(P3): a feature is malfunctioning
* Low(P4): a cosmetic issue
Now you see why Raj(tech manager) was arguing that the Print bug was a medium: a feature was malfunctioning.
Priority levels:
* P1 & Stopper: drop everything and take care of it as soon as you see this (usually for blocking bugs) because it may effect business perspective .
* P2: fix before next build to test
* P3: fix before final release
* P4: we probably won’t get to these, but we want to track them anyway
Now you can see why Ram was making the issue as a high(P1 Severity). From his perspective, it was a P1 matter,is't it?
Both are right according to their view. It’s of medium severity, but P1 to fix. Now let's start from Basic,
What is Severity? What is Priority?
--------------------------------------------------Priority is Relative; Severity is Absolute, Severity is customer-focused while priority is business-focused.
Priority means "“How important is it to the business that we fix the bug?". Most of the times high Severity bug is becomes high Priority bug, but it is not always. There are some cases where high Severity bugs will be low Priority and low Severity bugs will be high Priority.
Further, the priority might change over time. Perhaps a bug initially deemed P1 becomes rated as P2 or even a P3 as the schedule draws closer to the release and as the test team finds even more heinous errors. Priority is a subjective evaluation of how important an issue is, given other tasks in the queue and the current schedule. It’s relative. It shifts over time and it’s a business decision.
By contrast, severity is an absolute, it’s an classification of the impact of the bug without regard to other work in the queue or the current schedule. The only reason severity should change is if we have new information that causes us to re-evaluate our assessment/classifiation. If it was a high severity issue when I entered it, it’s still a high severity issue when it’s deferred to the next release. The severity hasn’t changed just because we’ve run out of time. The priority changed.
Priority and Severity Don't Mix
-----------------------------------------------
According to tech guru's "Never mix Priority and Severity to compose the Risk level".I suggest using such an approach with extreme caution. It’s multiplying apples by oranges in an attempt to quantify bananas. Risk is yet a third type of information. It should be handled/majored differently.
Establish Work Precedence
-----------------------------------------
The best way to avoid confusion about what comes first is to ensure everyone in the organization takes their cues for work precedence from priority and nowhere else. Developers fix P1 defects first. Testers verify P1 fixes first. Technical writers document P1 issues first. Everyone works in priority order: the priority reflects importance to the business. The severity rating is technical information used by managers as a piece of the formula in determining the priority rating. The priority rating is the final word on the order in which the work is done by programmers, testers, and everyone else.
Bug Triage/Bug council Meeting
-------------------------------------------------
Triage is a medical term. Which refers to divides wounded or sick people into three categories.
1.)Those who will die no matter what you do
2.)Those who will recover even if without aid
3.)Those who will recover only if aided.
In a situation where there's too much to do, you must concentrate on the third group. Bug Triage Meetings/Bug Councils are project meetings in which open bugs are divided into categories. The most important distinction is between bugs that will not be fixed in this release and those that will be fixed. There are three categories for the medical usage, software also three categories - bugs to fix now, bugs to fix later, and bugs we'll never fix. Triaging a bug involves:
A.) Making sure the bug has enough information for the developers and makes sense
B.) Making sure the bug is filed in the correct place
C.) Making sure the bug has sensible "Severity" and "Priority" fields
Example:
High severity and Low Priority
------------------------------------------
1.) Typo mistake in client name before 3 month of project release
2.) If there is an application if that application crashes after multiple use of any functionality (example--save Button use 100 times in same session then that application will crash)
Means High Severity because application chrashed but Low Priority because no need to debug right now you can debug it after some days. Very few user or no user will press save button 100 times in same session.
High Priority and Low Severity
------------------------------------------
1.) Typo mistake in client name before 3 days of project release
2.) A display functionality displaying a field called "6-Month Percentage ( ) Loss" showing values of 12500 which should be 12.500 . This is a 6-month analysis figure.High priority since you need to display the accurate percentage.Low Severity - it is a report displayed after every six months.
Conclusion:
I think definition discussed above is just a another story if two people who are fighting over Priority and Severity, if they do not agree upon above concept.
No comments:
Post a Comment