.
I was talking to a friend the other day about this and that going over a few ideas and stuff, when he came out with the best definition of Priority when associated with software defects. The typical definitions go along the following lines.
Priorities and Severities:
Priority is how important something is to fix, while Severity is how severe the impact is on the system as a result of the bug.
Priority:
The priority of a defect is based upon the importance and urgency of resolving the defect. Priorities are usually High (P1), Medium (P2), and Low (P3);
High (P1) – (Associated 1 with Critical (S1) and Serious (S2))
This defect must be fixed as soon as possible. Defect is blocking further progress in this area. It should be resolved immediately. (Must be fix within 24-48 hours. Blocking build test)
Medium (P2) – (Associated 1 with Serious (S2) and Moderate (S3))
This Defect should be fixed prior to the product release. It must be fixed as soon as possible. Bug is blocking further progress (testing) in this area
Low (P3) (Associated 1 with Moderate (S3) and Minor (S4))
This Defect should be fixed if time allows, it can be resolved in a future major system revision or not resolved at all.
Severity:
The severity of a defect is based upon the degree which the defect impacts the application. Severities are Critical (S1), Serious (S2), Moderate (S3) and Minor (S4).
Critical (S1) – (Associated with Priority 1)
The defect causes the system crash or loses data. This defect has no work around. Deviation between the specification and the behavior of the Application (causes the Application to function) No work around is available.
Serious (S2) – (Associated with Priority 1 & 2)
The Application will operate, but its operation is severely restricted. The defect causes major functionality or other severe problems; product crashes in obscure cases. This defect causes the system to produce incorrect, incomplete, inconsistent results or impairs the system usability. There is a work around. Deviation between the Specification and the behavior of the application (causes the Application to function improperly, i.e. incorrect totals, paint types, etc.)
Moderate (S3) – (Associated with Priority 2 & 3)
The Application will operate with limitations that are not critical to its overall operation. The defect causes minor functionality problems, may affect "fit and finish" of the product. The defect does not cause a failure, but impairs usability, and interferes in the fluent work of the program. Violation of standards, conventions, or rules that would not result in a deviation from requirements if not corrected, but could result in difficulties in terms of maintenance or clarity of purpose (workmanship)
Minor (S4) – (Associated with Priority 2 & 3)
Bug contains, formatting, typographical, spelling defect whose correct interpretation is obvious to a knowledgeable reader, or unclear wording of error messages in low visibility fields. The problem does not impact the use of the product in any substantive way. This defect affects nonfunctional aspects of the application. A work around is available. The Application can be used with only slight inconvenience.
This friend of mine put it more simply stating that a High P1 is something we have to fix or lose our customers, a Medium P2 is something that would be nice to fix but it can wait, and a Low P3 is something we will never get to so why bother. As far as Severity goes a Critical S1 is bad enough that it will cause Customer Support headaches with the increase customers calls, Serious S2 is something that the customer won’t like but they have a work around, a Moderate S3 is an issue we are betting the customer will tolerate, and a Minor S4 is something that the customer won’t even notice.
I believe he hit it on the head, how many times has a product been release with no P1s or P2s but a ton of P3s and P4s? The answer is every time a product is released. In the many years, I’ve been in the industry I have seen my friend’s definition put to use more often than not. I was working at a company which had defects 13 years old which have never been touched and the reason given for these defects being left in the product – the customer has not complained about it so it must not be a problem. Yep he has it right.
.
About Me
Friday, March 19, 2010
Friday, March 5, 2010
A recipe for disaster
.
I have worked at several companies throughout my career, which wanted to move from a waterfall methodology to agile methodology, and each has had its own unique set of problems. Even though they are different, I have notice similarities as company have tried to move in the direction of agile and the best way to describe them is by using the analogy of remodeling a house. It seems to be a best fit when describing the situation in software development.
In this analogy our faithful customer has a conversation with the architect who writes downs the customer’s ideas and formulates a plan to create a thing of beauty for the customer. When presented to the customer there is the normal back and forth discussion until there is agreement that what the architect has come up with matches the ideas of the customer. The architect takes the customer’s requests to a meeting with the drafters, the construction team, and the inspector and presents his vision of the additions and enhancement the customer is expecting in the near future.
The drafters and the inspectors take time to go over the ideas to achieve clarity on what is really needed to meet the customer’s desires. As the construction team begins this process the superintendant of construction says to the team we don’t have time to go over the architect’s proposal because we have too many other projects that need to be completed, first. So months goes by with no input from the construction team, until one day the architect inquires as to the progress being made on the customer’s request. The superintendant replies since the proposed project has not gone through the proper vetting process that the construction team had not even looked at the request and had no idea as to how long it would take to complete the additions and enhancements.
So after having the new process explained, the architect reworks the customer’s request and submits it into the process expecting a reply in a couple of weeks since that is how long the process is suppose to take. Two months later the architect is given a draft schedule and an indication of how long it would take to deliver the entire project. The end date is unacceptable to the customer, so negotiations on the scope of the project begin with an end date in mind the project’s scope is cut in half, though the architect is not happy, the architect needs to get something completed by the end date, and reluctantly accept the new plan.
The plan is put into action but to ensure the schedule is met, decisions that the team of drafters, construction workers, and inspector usually make on the fly for quick turn around, is now delayed as each decision must be estimated by the construction workers and than vetted by a committee superintendants in a weekly meeting, and can takes weeks to decide if a change can be made and its effect on the schedule.
When the end date arrives, there is much bickering, finger pointing, and blame being tossed around as the incomplete project is delivered to the customer. A root cause analysis is conduct to find out why the project failed, but it is not done using the 5 why of root cause analysis and blame is fixed on individual department and the results of the analysis is never seen by the parties involved. As a result of a superintendant wanting to make a point to another superintendant, the delay in beginning of the original project created a crisis at the end of the project.
The moral to this story is for superintendants to get out of the way and let the work progress, because everyone loses, when superintendants think more of their egos than they did of the project at hand. In an agile environment, egos have no place that the table and when the egos appear a recipe for disaster is beginning to cook.
.
I have worked at several companies throughout my career, which wanted to move from a waterfall methodology to agile methodology, and each has had its own unique set of problems. Even though they are different, I have notice similarities as company have tried to move in the direction of agile and the best way to describe them is by using the analogy of remodeling a house. It seems to be a best fit when describing the situation in software development.
In this analogy our faithful customer has a conversation with the architect who writes downs the customer’s ideas and formulates a plan to create a thing of beauty for the customer. When presented to the customer there is the normal back and forth discussion until there is agreement that what the architect has come up with matches the ideas of the customer. The architect takes the customer’s requests to a meeting with the drafters, the construction team, and the inspector and presents his vision of the additions and enhancement the customer is expecting in the near future.
The drafters and the inspectors take time to go over the ideas to achieve clarity on what is really needed to meet the customer’s desires. As the construction team begins this process the superintendant of construction says to the team we don’t have time to go over the architect’s proposal because we have too many other projects that need to be completed, first. So months goes by with no input from the construction team, until one day the architect inquires as to the progress being made on the customer’s request. The superintendant replies since the proposed project has not gone through the proper vetting process that the construction team had not even looked at the request and had no idea as to how long it would take to complete the additions and enhancements.
So after having the new process explained, the architect reworks the customer’s request and submits it into the process expecting a reply in a couple of weeks since that is how long the process is suppose to take. Two months later the architect is given a draft schedule and an indication of how long it would take to deliver the entire project. The end date is unacceptable to the customer, so negotiations on the scope of the project begin with an end date in mind the project’s scope is cut in half, though the architect is not happy, the architect needs to get something completed by the end date, and reluctantly accept the new plan.
The plan is put into action but to ensure the schedule is met, decisions that the team of drafters, construction workers, and inspector usually make on the fly for quick turn around, is now delayed as each decision must be estimated by the construction workers and than vetted by a committee superintendants in a weekly meeting, and can takes weeks to decide if a change can be made and its effect on the schedule.
When the end date arrives, there is much bickering, finger pointing, and blame being tossed around as the incomplete project is delivered to the customer. A root cause analysis is conduct to find out why the project failed, but it is not done using the 5 why of root cause analysis and blame is fixed on individual department and the results of the analysis is never seen by the parties involved. As a result of a superintendant wanting to make a point to another superintendant, the delay in beginning of the original project created a crisis at the end of the project.
The moral to this story is for superintendants to get out of the way and let the work progress, because everyone loses, when superintendants think more of their egos than they did of the project at hand. In an agile environment, egos have no place that the table and when the egos appear a recipe for disaster is beginning to cook.
.
Subscribe to:
Posts (Atom)