Monday, July 27, 2015

How to Prioritize Stories in Agile

Overall speaking, you should always be picking up stories which have the highest business value or highest customer need.

Agile has emerged as a major software development methodology, a mindset and a philosophy to run businesses. What’s your in-depth understanding of this Agile principle "Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.” Why do so many agile teams prioritize stories because it is a low hanging fruit (easy, low effort) but not high value to the customer? What’re your approach to set prioritization right?






Prioritization means working on them as per the client's priority. The teams should be working on the items that will bring the most value to the customer and correspondingly to the business. If you prioritize by doing the easy stuff first, you will always be trapped into doing what you CAN do instead of what you SHOULD do - the hard, but potentially game-changing or high delight items will always fall to the bottom of the heap. Make your Product Owner focus on what's right, not what's easy. In other terms, the team prioritizes those stories higher in stake rank which are going to provide maximum ROI to the client (and so high value to the customer). Although, there can be other factors like dependencies which may impact prioritization, most of the time ROI to the client is the single most reason affecting prioritization of stories. The value is not the only factor that accounts for prioritization, the PO owns the value and business risk, but the team owns the technical risk and all contribute to the prioritization.


Value is a subjective thing. Just saying value, by definition, is to compare benefit vs cost, so cost cannot be eliminated from the value proposition. Also, the importance or priority or urgency of doing something is usually related to its value, but there are often other considerations as well. If low hanging fruit improves how your product is viewed and received by users, even if it doesn't do wonders for their lives, it has value. If the value returned is worth the time put into it then do it. If it doesn't give you a good ROI for your time then it really isn't low hanging fruit and it probably shouldn't be in your backlog. That value judgment depends on.
-Is it building your reputation & relationships?
-Is it driving out risks and fear?
-Is it going to teach you useful things?
-Will it help a customer solve a problem?
-Will it make your team/employer more money?
-Will it be good training for a new hire?


The biggest waste of all is to build something the customer doesn't want. Your company typically makes many assumptions in its planning, the most important one being "someone wants what we're building." From a business point of view, the most important stories are the ones that validate (or refute) those assumptions. The only way to conduct this particular experiment is to build the stories that provide the most customer value and then see if anybody's interested. If you don't do that first, then everything else is a waste of time. Customer value, then, is the only prioritization criterion that makes any sense at all. It doesn't matter if it's "Agile" or not - it's still wasted effort. Unused features drive up technical redundancy which has to be dealt with and adds to the maintenance overhead. And - there is the opportunity cost of not working on the highest-value feature. The perspectives certainly play to the theme of "what's the definition of value?" Consider a scenario where there is a story to address something that is more annoying than it is valuable. However, it's very simple to address, and you have the capacity in this sprint to get it done and delivered and score a win for those it annoys. Prioritization and value often are complex to define as they have many factors.


Achieve clarity on the request before rebutting the argument. The crux of the scenario lies within the question itself. If there really is little value in the features to the customer then why are the stakeholders asking for low-value stories to be prioritized? But perhaps you need to get to the reason that stakeholders aren't willing to ask for the higher value but more difficult stories. Can you show them how the team can reduce risk, or deliver part of the value sooner? the point is not "is it agile" but getting to the root cause of the behavior! One can also argue that if the stakeholder wants it prioritized, then by definition, it's a high-value story to the stakeholder. Which isn't to say that it'll bring value to the customer. In this case, the stakeholders' values are misaligned with the customers'. Or, maybe there's a lack of trust? If the product/dev team has a poor track record, maybe the stakeholders want to see small, incremental progress to help build the muscle memory of delivering working software? The perspectives certainly play to the theme of "what's the definition of value?"


Fail Hard, Fail Fast, should be the approach! So tackle the risky items first that add business value. When the team gets used to putting high-risk items last on the list, they do not build the fearless attitude! First, you want to completely eliminate waste and only deliver the barest minimum to solve the business problem. Think of it as a working prototype that is production quality code and tested. It proves that technically it can be done and it works. This Minimal Viable Product is a massive sigh of relief to many people as it proves it works and can be done. Risks are radically reduced. Then next is to build all the supporting features that make it a product.


There are instances where quick wins benefit the product evolution, but you shouldn’t prioritize them ahead of market/customer drivers. Delaying functionality that you can monetize because it's harder is usually not a good bet. Overall speaking, you should always be picking up stories which have the highest business value or highest customer need.

0 comments:

Post a Comment