“efficiency is about doing things right, while effectiveness is about doing the right things”
JIRA is a great issue/task tracking system but I’m not convinced not having a severity field by default is a good idea, their explanation is;
“The Severity field was removed for a number of reasons, but principally because it was confusing to business users. To a software developer, it seems obvious that the severity of the bug ("The system crashes completely") is unrelated to the priority of it ("There is a one in a million chance of this occurring"). However, JIRA succeeds so well because business users can actually use it. If you present a business user with these two fields, they are instantly confusing (which is why the Severity field was removed). “
This is a convincing argument. Although, I would suggest that not having severity over simplifies the decision making process. A decision probably best answered for each project individually – experience tells me the business is more inclined to be upset if they create a high severity record and the tech team mark it as low priority.
Decision making
As well as severity and priority should all projects now consider Technical Debt and Financial Cost associated with work items?
Managers require data to enable effective decision making, while a developer may perceive more fields as just being an additional overhead distracting them getting the job done. Technical staff need to be aware of the business benefits and costs of doing something. Spending days refactoring code because the coding standards are not met is not effective if a bug was never reported to do with the code. This is especially true when critical issues aren’t investigated.
I believe Priority, Severity are indicators of technical debt and time to resolve the task is the financial cost. Is it possible to put a value on technical debt? I’m not convinced there is, what I do know is that not paying it off early enough can be very, very expensive in the long term.
As a manager it is important to listen to a team concerned about issues in code and design, the team are responsible for effectively communicating their concerns.
Worthwhile reads – completely un-related to this blog entry but got me thinking…..
The Kumbaya irony - Are you having fun with technology for no apparent business reason.
What is Participative Leadership? – getting staff involved in making decisions.
Bibliography
Why doesn't JIRA have a Severity field like Bugzilla?
Finding the value in technical debt
Refinance Your Technical Debt Just Like Your Mortgage
Paying Down Your Technical Debt
Technical Debt – great diagrams!
No comments:
Post a Comment