For me there are two major smells when it comes to prioritization, and you can identify them by asking someone «What are the most important tasks we should work next?», if this someone answers:
«Everything is important!», that person is lost, does not get the business, the product, the clients, will harm the team and the company.
«What are the easiest to complete?», again, this person is lost, does not get the business or doesn't care and is just there filling a hole. Going for the low hanging fruit without understanding the value of completing a task is quite bad.
To know what to do next, in what order and when; you need to know two things per task or goal:
Effort: How much costs/effort/work takes to make this change to the system.
Value: What is the value it brings to the clients, business, users. Are they going to use this feature?
Effort is complicated, it is the work required to take the system from one state to another. That implies too many things: how complex is the system, how complex is what you want to do, how well trained in the system is the person that will perform this task. Keeping a system simple and flexible helps a lot to keep the amount of effort low.
Value is dangerous, specially if you guess. If you think that "putting that text to the right is more effective for your customers" but you don't have data on this, you are guessing... and that's fine but if you are going to get into a complex task you better make sure that you are taking this decision base on data and not guts.
Take into account also that every modification you apply to a system changes it's complexity and value that it delivers. Also it takes some time to implement correctly, the more simple something is the less time it will take to execute and integrate harmoniously with the rest of the system. The ideal would be minimize complexity and maximize value in the shortest time possible, but there are few cases when this actually happens.
So basically the only thing we can do is to trade simplicity and effort for value. If something will introduce a ton of complexity in your system but not added value, it has a negative impact. Because complexity makes the system harder to change in the future, probably adding rigidity and more cognitive load on the developers. So that kind of changes is better not to do them, except you intentionally want to harm your company.
Remember always that you were hired not to get things done, but because you ultimately know, you know everything inside out. You are there to say NO and stand. Because if you don't say NO, who is going to say it? You are there to get things done but also to prevent the non-technical people from killing the company, don't be a yes-person.
Some managers would get angry at you about this, but please explain your self, explain the tread offs.
Check part II here.
Oldest comments (0)