I am quite new with prioritization requirements in agile. As we know, normally, during the prioritization process in agile, business value is the most important factor that taken into consideration.
Are there any other important factors that will take into consideration while doing the requirements prioritization in agile, in order to make sure that the software will deliver on time.
It might even be a stretch to say that business value is the most important factor. Overall, prioritization often comes down to a ROI, but a lot of factors can feed into that, such as:
Types of Value
There is revenue, but there are many other types of value. Security adds value for many companies, as does other hard-to-quantify items like brand recognition, customer satisfaction, and reputation. Then you have other forms of monetary value, like cost savings.
Types of Cost
Even the cost side of ROI can be complicated. Is it a once-and-done cost? Is there a recurring cost, like software licenses or support contracts? Unknowns and risks also represent potential costs.
Technical Considerations
This is a bit of overlap with costs, but it may be impractical to prioritize in a certain order because of how something is build. Now, I'd say that 90% of the time I hear this, it's not true - it's just easier to build it one way, which means that the PO should really justify why the extra cost is worth it to prioritize a different way or they can lose the trust of the team.
Politics
Like it or not, we're humans and there are politics in any organization. They might not be mean and complex, but they are there. Maybe a department has been neglected for a while and creating a feature for them will go a long way in turning them from a detractor into a supporter for your department or team.
Work in Progress
It would be nice if nothing spilled over between sprints, but sometimes it does. There is an assumption that anything spilling over must be at the top of the priority list, but I'd encourage an active conversation about this. It doesn't have to be, but it introduces a huge risk to leave half-done work sitting around. In fact, usually when a team decides not to continue spill-over work, they instead take on the work of backing it out, which means whatever replaces it better be really important.
So, what do we do with all of this? There are a lot of prioritization models out there. Some incredibly complex with lots of spreadsheets and math, others incredibly simple where everything is reduced down to one point estimate for "value" and one for "cost". Personally, I like to list out the major categories, give them each a multiplier to signify how they rank against each other, and then do relative estimation for each feature on each criteria. That gives you something to work with at a feature level and then when you get down to stories or PBI's, I find you can use your instincts and that combined with what you had at a feature levels keeps you in a good prioritization, but that's just me.
As we know, normally, during the prioritization process in agile, business value is the most important factor that taken into consideration.
This isn't actually true. A Product Backlog should be ordered, but the order can be based on any factors (or combination of factors) that the Product Owner considers important. Pragmatically, a Product Backlog is ordered based on a combination of:
business value
May include return on investment, bang for the buck, speed to market, total cost, etc.
related feature sets
Clustering themes and related features together can optimize resources (including the team's cognitive load) or provide a more cohesive feature set for targeted release dates.
low-hanging fruit
Some stakeholders like to knock out the easy stuff first to get traction or reach a Minimum Viable Product.
identifying the hard stuff
Some projects benefit from solving the tough problems first. There's no use spending a lot of time and money on a project where some critical aspect is found to be insoluble late in the project's life cycle.
resource availability
Prioritizing the stuff you can do now is important. If your supply chain won't get you your widgets until next quarter, prioritizing widget-embiggening stories makes very little sense.
market conditions
If you have Feature A and Feature B on your backlog, it generally makes more sense to prioritize Feature B if you have a customer already lined up for it. Marketing is important, but paying customers are better.
everything else
The Product Owner is in control of the Product Backlog, but they should be collaborating with the rest of the organization and the project's key stakeholders to ensure that the backlog takes all the disparate (and often competing) objectives into account.
There are many techniques for prioritizing backlog items, including Theme Screening, Theme Scoring, Story Weighting, and others. It actually doesn't matter how you prioritize it, so long as all the stakeholders in the organization agree on the methodology.
Looks like nobody has mentioned the MoSCoW method yet, so I'll throw that in. Must have, Should have, Could have, Won't have ... apply this framework to whatever requirements you may have and it should help you prioritize. Going through this process will help you think about more than just "business value".
Business Value is a key factor however,we may also want to look at other factors like 1.How many Users will be impacted. 2.What could be the risk involved with the implementation 3.Cost of delay. 4.Who is your customer? ,What is the value add to them?
Product Owners are the ones who are vested with the authority to assign and change priorities. Product Owners are almost always razor focused on business value. In my experience many POs (not all ;)) tend to not just overlook but actively resist technical team's request to give priority to catching up with technical debt, even high risk ones.
Considering OP is specifically asking for considerations other than business value, I will say "Technical debt" is the big one.
