Every agile team is faced with decisions about which requests or user stories to prioritize, and the choice can often be difficult‒especially when we’re expected to adapt to rapidly changing requirements.
When working with stakeholders or external team members, the process can be even more stressful as requests build up; stakeholders with competing interests may express disapproval if their requests are not prioritized over others or not completed in the timeframe they desire.
In these situations, it’s essential for an agile team to be able to de-prioritize or defer work to a later date, because time and resources are finite while requests can be infinite.
Many stakeholders will regularly check in on the progress of their requests and become frustrated if progress is not made as quickly as they prefer, however, in many cases, there are rational reasons for allowing new requests and work to supersede existing requests.
At some point‒or perhaps even frequently‒your team will need to explain why a request was deferred or de-prioritized, which can become an uncomfortable situation. To help you best prepare for this discussion and explain your decision, here are 10 common reasons why your team may need to de-prioritize a request and some examples of how you can explain your decision.
1. Newer, More Valuable Requests Have Been Introduced to the Team
Possibly the most frequent reason a task has been deferred is that more valuable requests have come up, which represent more value than older requests. Because agile teams are expected to adapt to changing priorities, and we can’t complete an infinite amount of work in a finite amount of time, something needs to be pushed a little further down the priority list or roadmap.
To help explain this, start with why the new request is very valuable and important to your users and organization. While it’s also important to explain why the older request is not comparatively as valuable, you may want to avoid beginning the conversation with reasons the request was devalued relative to new requests, and focus on the new opportunity being presented.
If the stakeholders care about the users and what’s best for your organization, they should understand why it’s important to complete newer requests that provide more value to the users you’re ultimately building the product for.
2. The Request Is No Longer as Valuable to the User
Sometimes the requested work will no longer deliver as much value because conditions change. For example, if a stakeholder requested your team build features that help users sort their recyclables into aluminum, plastic and paper, but the government no longer requires sorting of recyclables into categories, the request becomes far less valuable and possibly not valuable at all.
When explaining this scenario to your team, start with explaining the original value proposition (i.e., sorting recyclables), explain what condition changed (i.e., government regulation changed), and then explain how that change reduces the original value proposition (i.e., the change in government regulation reduced the need to sort recyclables).
3. The Request Is No Longer as Valuable to as Much of Your User Base
Let’s say you’re working on a product focused on college students at a select set of universities, much like Facebook did when it started. You may get requests specific to college students, such as advanced features for managing tuition, securing financial assistance for college and educational curriculum management.
However, your product may evolve the way Facebook did, to serve the entire world’s population above a minimum age such as 13 years old. Suddenly, requested features like securing financial assistance for college are only delivering value to a smaller percentage of your users, whereas previously, they benefitted all of your users.
Again, when explaining your decision to de-prioritize the request, explain the original value proposition and what changed to reduce that value proposition, but this time end by explaining how the change decreased the percentage of users who would receive value from completing the request.
4. The Request Deviates from the Updated Roadmap and Product Goals
Pretty much every roadmap needs to be adapted and modified at some point as product goals shift, and when this happens, there will be requests which are no longer as relevant.
For example, in the social network example above, it’s usually a conscious product strategy to shift from focusing solely on a niche market like college students and target a wider audience like the entire global population. During this transition, your current user base may still be college students, but you’re attempting to capture new markets with new user bases.
In this case, your explanation should start with what the original value proposition was, then explain the shift in your roadmap, then explain how the original value proposition no longer delivers the same value to your target market‒even if they’re not your current users yet.
For example, “The student loan management feature was very valuable when we were focusing on just college students, but our organization has decided to change our target market to include the entire global population; therefore the student loan management feature will only provide value to a small set of our target, expanded user base.”
5. The Request was Satisfied Another Way
It’s not unusual for a request to be satisfied another way, which makes the original request irrelevant or unnecessary. For example, a stakeholder may have asked you to build an electric scooter, but your team first built an electric bicycle that delivered more value to more users.
Once the electric bicycle was released, users who originally asked for the scooter ended up trying it out, and found that it met most of their transportation and enjoyment needs. Since most people were satisfied with the electric bicycle, they no longer saw urgently needed value in having an electric scooter.
In this scenario, explain the value proposition of the incomplete request, explain the value of the request that was completed, and then explain how the completed request provided the same or similar value to the user and how it decreased the user need for the incomplete request.
6. Completing the Request Presents More Risk Than it Previously Did
As your product changes, introducing new features or bug fixes can become more and more risky, as features and code start depending on other areas of the product.
For example, let’s say you’re building a publishing website that starts out with just basic blog posts. As your product matures, you develop more features that rely on blog posts‒feeds, categories, comments, tags, social sharing, canonical URLs, preview snippets, advertising and more.
When you were first building the product, someone requested private members-only restrictions on some content. Back when the only feature on the site was blog posts, this seemed pretty straightforward, but now that you’ve got a bunch of features relying on this core feature, things get a little more risky in terms of what can go wrong.
For example, could secure content introduce problems with SEO meta data, preview snippets, feeds and comments? Could disruptions in feeds be seen as a bug? Could email notifications about comments that are no longer accessible to non-premium members be seen as a bug? What about actual bugs?
For this scenario, the value to the user didn’t change so much as the risk presented by implementation. First explain the relatively lower risk of the request in the past, then explain the conditions that resulted in elevating the risk of implementing the request.
7. The Request Would Now be More Difficult to Support Than Previously
Similar to the above example of elevated risk, sometimes the resources needed to support the implementation of a request become elevated over time. A lot of the time, this is due to scale and complexity of the product, as well as user behavior.
For example, unlimited frequency of Excel exports for huge tables of data would be much easier to support if your user base was small and not expected to grow, but if you added a large number of users over time, you may want to put some restrictions on how frequently users can pull data and how large the sets of data can be to avoid crashes that harm all users.
In this scenario, explain the original resources needed to support the request at the time it was submitted, then explain what changed (i.e., user base size) which escalated the difficulty to support the request in the current state of the product.
8. The Request Could Be Better Handled by Other Resources That Weren’t Available Previously
Sometimes the resources available external to your team change and can better handle requests that were originally submitted to your team.
For example, maybe you were the founding team of developers at your company, which has since expanded to include teams focusing on specific sets of features or markets.
Your team no longer should handle all requests, and it’s very likely another team or resource will be more focused and do a better job on the request. Maybe the team of developers handling ecommerce features would be better suited for building out a new shopping cart feature.
In this scenario, explain the new resources that now exist and why they’re better suited for handling the request. Sometimes it’s developers, but sometimes it could be another resource like more manual workers or skilled workers who can perform data manipulation and custom reports in Excel, for example.
9. It Turns Out the Request Was Far More Difficult Than Originally Estimated
Similar to other examples above, sometimes changes in the product or other external factors make a request more difficult or costly than originally estimated. Going back to the content publishing website example, adding more and more features can make it more difficult to implement additional global features that interact with that newly expanded set of features.
In this case, explain the difficulty of the request when it was originally made, then explain what changed and how that increased the difficulty of implementation.
10. The Request Would Be Less Frequently Used Than in the Past
Whether it’s a change in your user base size or a change in user behavior, sometimes requested features just won’t be as frequently used as originally anticipated. A common scenario that comes up frequently is around bugs and bug fixes.
For example, you may be working with a video player technology that doesn’t support a specific browser as well as another video player, and a stakeholder may request that you change video player technology to better support all browsers because users are seeing too many errors.
However, your user base may shift their behavior and start only using the more widely supported browser, making the frequency of the video player error much lower.
In this scenario, you can explain the original frequency of the problem or need, and then explain what factor changed and led to a decline in the frequency of the problem or need for users.
It’s Not Always Fun, but It’s Why We’re Good at What We Do
Telling a stakeholder that their request is no longer as high of a priority as it previously was will rarely make them happy, and they may actually have negative feelings about this news.
However, shifting priorities is a key aspect of every agile team, and ultimately a main driver of what makes us effective and successful.
Hopefully the examples and scenarios in this blog post can help you better prepare for some of those more difficult conversations. Happy de-prioritizing!
What do you think? Let me know in the comments below.