Mine is more a social solution than a tech one. Hope that counts here!
Years ago I came up with a simple equation for determining priority of software engineering bug fixes and small features:
Priority = (Benefit the feature provides to the product) / (Time to complete the feature)
where benefit is defined by the business side using any scale (say 1-100), and time to complete is defined by the assigned software engineer using any unit (perhaps man-hours). Regardless of what range the numbers fall in, 0 to 1 or 0 to 42, you end up with an ordered list of tasks which equally value business value alongside engineering time.
I came up with this while working at a medium sized company. I was frequently tasked with too many things to do. Despite tasks being organized in a Redmine-like tool, the implementation was still done in random order because nobody could define priority. This led to much miscommunication about what I was working on in the recent past and future. I used the equation to better communicate my activity and future plans with the business side. Given an ordered list of tasks from this equation, anyone could see clearly what was being worked on next.
The business side resisted attaching a numeric benefit to the features, presumably because that's hard. But it's equally hard to define the time to complete a software engineering task, and I eventually convinced them we needed to at least try to be scientific about both.
n.b.: I used this while working on a mature system. For a newer project or for tasks with more dependencies, it's probably still complicated to define priority. In the setting I was in, it worked great.
My boss's boss however thought it was condescending and nobody aside from myself ever made use of it. I hope to make use of it again one day, but after one bad experience with a medium sized company, I've stuck with smaller places where this is not as necessary.
Years ago I came up with a simple equation for determining priority of software engineering bug fixes and small features:
Priority = (Benefit the feature provides to the product) / (Time to complete the feature)
where benefit is defined by the business side using any scale (say 1-100), and time to complete is defined by the assigned software engineer using any unit (perhaps man-hours). Regardless of what range the numbers fall in, 0 to 1 or 0 to 42, you end up with an ordered list of tasks which equally value business value alongside engineering time.
I came up with this while working at a medium sized company. I was frequently tasked with too many things to do. Despite tasks being organized in a Redmine-like tool, the implementation was still done in random order because nobody could define priority. This led to much miscommunication about what I was working on in the recent past and future. I used the equation to better communicate my activity and future plans with the business side. Given an ordered list of tasks from this equation, anyone could see clearly what was being worked on next.
The business side resisted attaching a numeric benefit to the features, presumably because that's hard. But it's equally hard to define the time to complete a software engineering task, and I eventually convinced them we needed to at least try to be scientific about both.
n.b.: I used this while working on a mature system. For a newer project or for tasks with more dependencies, it's probably still complicated to define priority. In the setting I was in, it worked great.
My boss's boss however thought it was condescending and nobody aside from myself ever made use of it. I hope to make use of it again one day, but after one bad experience with a medium sized company, I've stuck with smaller places where this is not as necessary.