Keeping “IT Fit” and prioritizing requirements during software development takes both disciplines and practices, but it is worth the effort.
We live in the era of information overload and “data-obesity,” IT organizations at the center of such changes, also suffer from work overload and understaffing challenges, and most IT organizations have such a reputation as a cost center and lack of speed. How do you prioritize IT initiatives, and which requirement prioritization technique is most often used in Agile development?
We live in the era of information overload and “data-obesity,” IT organizations at the center of such changes, also suffer from work overload and understaffing challenges, and most IT organizations have such a reputation as a cost center and lack of speed. How do you prioritize IT initiatives, and which requirement prioritization technique is most often used in Agile development?
Business Value will always be an important consideration. The risk will sometimes be an important consideration. Opinions on priority change with time, so you ought to have something that allows ready re-prioritization whenever needed, to ensure that your backlog allows this. Maximizing the learning from the work you do will certainly be a consideration in the early stages of a product that has more than nominal risk. So typically the prioritization of features is "High Risk, High Value" first; "Low Risk, High Value" second; "Low Risk, Low Value" third; "High Risk, Low Value" Never. Try not to do more work up-front than you need to. Business people should know the business value and the risk from a business perspective. It might take some eliciting unless they are accustomed to evaluating risk and value. Technical people should be able to give you an initial idea on the cost and the technical risk, and on their capacity to adjust to the risk later if the feature doesn't get prioritized.
You need to work out with your customers to identify which feature *are* high value. It concentrates their minds quite well, usually, if you go into a prioritization meeting with a story that is clearly low value, and suggest that you will do that one first unless they have better ideas. You have to take into consideration the dependencies between requirements, even this requirement has low business value and high risk. "If there are some requirements depend on another" - Talk about features; things would deliver visible business value. Ask whether they deliver value on their own. Try to keep the "requirements" at this level. Let's take a simple case - "Log in," that of itself gives absolutely no business value. However, it is often the case that the system will want to know who originated a request or command to the system so that it can do its job properly. It is occasionally the case that the system will need to check and enforce constraints on permission to do certain things; in this case, the system is likely to need some degree of assurance that a user is who they say they are. There's the value from governance and risk management perspectives. Further, when following Voice Of the Customer, sometimes the customers don't know what they want. They have a lot of requirements and they need to see the system work. Therefore, the product owner has to have a requirement prioritization technique to prioritize the requirement and facilitate the development team and deliver the project on time and as the customer needs.
The challenges are to get multiple "masters" to agree upon somethings prioritized. The constraints in requirements prioritization often have more to do with the fact that the backlog serves multiple "masters." As the central application supporting multiple lines of business, getting cross-business prioritization is the largest barrier. So you have to get the various stakeholders to assign a value to each item in the backlog. Where the values differ, let them negotiate and agree upon something, and if required things escalate up their lines of management. Refuse to add any item to the backlog until it has a value that has been agreed upon and signed off. You will still need to prioritize items that have a similar value, but it should help.
Keeping “IT Fit” and prioritizing requirements during software development takes both disciplines and practices, but it is worth the effort, and it is a significant step to transform IT from a cost center to value creator; from a back-office function to a customer-centric business enabler, from an order taker to a strategic business partner to deliver business VALUE as the first priority.
0 comments:
Post a Comment