2 ms·
There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and o
by twic 6y ago
There may be a similar legibility point about severity levels. Some boss somewhere has to put the set of tasks in priority order for the development team, and once it's in that order, severity levels are useless for the developers. But they might be useful as a way for the person submitting the issue to communicate something to the boss who does the ordering.
Say there's a billing system. One of the accounts receivable clerks notices that due dates aren't properly adjusted for public holidays. As a developer, do you know how big a deal that is? Probably not. Doesn't sound like a big deal. But maybe it means we're imposing penalty charges on customers where we shouldn't be, and that's a huge legal and reputational risk. Or maybe it really isn't a big deal! The boss will need to have a conversation with the clerk to learn all this, but maybe having a severity field is an ice-breaker for that conversation.
- ydlr 6y agoWhy not have the clerk assign the severity? Why can't the programmer and clerk discuss the problem themselves if there is uncertainty? The only problems in your scenario arise from the introduction of a boss as go-between.
- twic 6y agoI am proposing that the clerk should assign the severity. You could have the programmers do the prioritisation, if they had the business understanding to do that. In that case, they're also the boss. The severity assigned by the clerk could still be a useful starting point.