If you didn't read the first part go there and read so you get some context.

So to know what to do next and in which order to execute, you will have to know how much value and effort takes each of the goals you want to achieve. After you have this clear you can classify them in 4 groups and this method also helps you to prioritize tasks. Identify for your business what are the most valuable things that you can do without complicating things too much.

High value / low effort

Quick wins, but don't confuse them with "quick & dirty" solutions. Quick wins are well developed, tested, consistent with the current architecture and simple modifications that you can apply and get a lot of benefit from. They don't introduce a lot of complexity but will give you a lot of value. This are the first tasks you need to attack.

What doesn't classify here?: a hack. If your quick solution, creates a problem for later, even if it looks like low effort execution now, i twill complicate things in the future, and when this "hacks" accumulate they will come for you in the more inadequate moment and hit you where it hurts the most.

High value / high effort

As this game is not always about taking the low hanging fruit. There will be complex features that will introduce complexity and need a lot of time to complete because they need to get done A, B, C, D and E. But they are business critical, and you have to get them it doesn't matter what. How to work on this ones? How to deal with them?

My advice, is evaluate if you really need the to go that path. Be careful, do your clients will really benefit from this features? are those existing clients and you need this to keep them? or are those "imaginary clients"? Existing clients are usually more valuable than potential or imaginary clients. Don't go into this kind of tasks because the sales team is pushing you, or the CEO came with a great idea, or whatever else... Use as much factual data as you can to decide if you really need to execute this.

But if you really need this task done don't lay down a 3 month plan or something like that. Specially because complex tasks have a high level of uncertainty and you have no clue on how to estimate them and you don't have a clue on how to do whole trip to the end. So, select the simplest and more independent thing that the team can work that will lead you in the goal direction. If you have clear intermediate milestones well, good for you... but sometimes I personally had not, I knew what I wanted at the end but was not until I started working that I was able to identify what was the next step to slowly climb to the top. So, if you don't have everything clear, that's fine, just keep an open mind in case you have to abandon or change path on the way there.

Very important for me is that this tiny milestones can be deployed to production when they are completed even if they don't make too much sense by themselves alone and that they are small, sometimes just a few hours of time, a day or two. But having something in production quickly gives you immediate feedback and that's very important to change course if you have to.

In this case I don't do any kind of estimates, because long tasks will be interrupted by smaller ones that will be interleaved, because you can't stop time and work for 3 weeks in a bubble; things will happen and that's fine. So, if your boss asks, just be sincere: You have no clue, but you will work towards the goal until completion, and you have this clear milestones, and you should have at least something small to show soon. I had done this, some people don't like it, but I prefer not to lie and pretend to be a know-it-all.

Low value / low effort

This tasks usually are not part of the critical path towards success. But are nice to have. My advice is to use them for people joining the team. Is very nice to come to a new job and that same day get something out in production. Also they are good for training interns or mentoring junior developers or keep a senior engineer from being bored or tired of working in big stuff. This kind of tasks are usually refreshing to do. So this ones are not a big deal.

Low value / high effort

Just don't! No, no, no... Don't! Even if someone tells you that is very nice to have, if you know that the cost is way higher than the benefit just don't... This tasks have overall negative impact. It is preferable to have a simple system than a complex one, it will make you fast, have a happy team, reliable software.

Wrapping up

Keep in mind every time you make a commitment your boss will hold to it and will come for it later. So, try not to make many commitments... just work and deliver valuable chunks of work, always open to the needs of the organization and the business. If you are not lazy you will achieve what you want, it just takes time to build things in the right way and make the process sustainable so there is a tomorrow after you complete a goal.

Remember that working producing software is a very very long way, you will have to maintain that software probably until no one uses it. So is not a race, is not sprints (specially not the SCRUM ones), is a marathon. Your software needs to adapt and be flexible. Don't let someone that doesn't work in your code base push you to screw it up, or negotiate with you and your team time with your family and friends, your nights and your life.

Keep it cool!