At ClickPoint Software, we’re always striving to make our software as great as possible. By examining what we do well and what type of functionality our customers are looking for in lead management and automation software, we’re constantly updating our list of new feature ideas. We know that deciding what we don’t do is just as important as deciding what we should do. In dealing with development timelines and support, there are frequent points where decisions must be made as to what any particular development team should be working on. Most development companies have finite and often limited development resources. In these instances, a plan for choosing what developers should be working on is needed. Here’s the process of how our development team decides which tasks are worth pursuing.
Issue Type
Most issues that development teams encounter fall into 3 categories: Bugs, Adjustments, and Feature Requests. In general, bugs have an inherent high priority. This is normally due to the fact that bugs are more visible to users than missing features. Some bugs can prevent proper usage of the system and should be ranked higher than others. Adjustments and Feature Requests can both be ranked moderately lower. The priority on these is usually proportionate to the need of the client and the associated client’s potential value.
Severity
While usually associated with bugs, this can also be deemed the importance of a particular adjustment or feature request for a client. Issues should be ranked within the relative range of their issue type based on their particular severity. This could potentially put a critical severity feature request above a trivial severity bug, depending on the context.
Deadline
Issues approaching hard deadlines (or worse, past established deadlines) should acquire higher relative priorities. In most cases, only severe bugs should have enough priority to push an issue over its deadline.
Time Requirement
Depending on the current flow of the development timeline, this facet can either raise or lower the respective priorities of issues. If there is a small period of time before a major high-priority issue with a deadline needs to be started, the relative priority of short-timeline items increases. This is because there’s usually no added value to completing a planned feature request release early, but getting quick bugs out of the system increases the overall stability and user perspective on the software.
Difficulty
In general, difficulty is going to have implicit impact via the time requirement. In some cases, however, with limited resources, difficulty can have an additional impact upon development. This is because some development team members may not have the required skillset to handle the issue. In these cases, the relative priority of the issue will reduce to zero on those who are incapable, and potentially rise on the developers who are capable, due to the exclusivity of the issue.
So how does this help me?
While there’s no universal formula for choosing development timelines, any development team should be aware of the factors that make these decisions. Teams will need to track this information against their ongoing performance to fine-tune the formula they use. This will aid in streamlining the development process and ensuring that development assets are properly allocated.
Example Math
To provide an example of some possible values:
Issue Initial Value:
Bug: 100
Adjustment: 80
Feature Request: 60
Severity Modifiers:
Critical: 120%
Severe: 100%
High-Priority: 85%
Moderate: 70%
Low-Priority: 50%
Trivial: 30%
Deadline Modifiers:
20% ahead of schedule: 60%
10% ahead of schedule: 80%
On Schedule: 100%
10% behind schedule: 120%
20% behind schedule: 140%
In order to use these values, here are some example issues:
A) Severe bug: 100 * 100% = 100
B) Moderate bug: 100 * 70% = 70
C) Trivial bug: 100 * 30% = 30
D) High-Priority Adjustment, 20% ahead: 80 * 85% * 60% = 40.8
E) Moderate Adjustment, 20% overdue: 80 * 70% * 140% = 78.4
F) Critical Feature Request: 60 * 120% = 72
In this scenario, the “ideal” development approach would be:
A, E, F, B, D, C
