BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Why Companies Need to do a Better Job of Prioritizing Features

Why Companies Need to do a Better Job of Prioritizing Features

Bookmarks

During a client meeting, the Director of IT was clearly frustrated.  "We have all these features to complete and there is no way we will get it done by Valentine's day.  I thought Agile was supposed to make things faster."  I told him, "Agile helps, but what we really need is some kind of prioritization on these features."  His reply, "They are ALL top priority."

Diffusion of Responsibility

When everything is high priority, nothing is high priority, and we fall into a miasma of finger pointing and misplaced expectations.  Here is why companies need to do a better job of prioritizing features.  Wikipedia defines diffusion of responsibility as "... a sociopsychological phenomenon whereby a person is less likely to take responsibility for action or inaction when others are present."  Weak or nonexistent prioritization creates a certain type of diffusion of responsibility.  Teams feel overwhelmed, stakeholders don't get what they want when they wanted, and project managers feel nullified.

We don't know everything about the project when we start

Yet we place a high premium on getting every requirement "nailed down" so we don't miss anything.  This is a fools errand.  There will always be items that were not considered.  Even if we did know everything at the beginning, things change.  New requirements emerge, gaps are discovered, and new opportunities present themselves.

Welcome to MoSCoW

The MoSCoW method is a prioritization technique to reach a common understanding with stakeholders with the importance of features vs each other.  It is also a fantastic lightweight prioritization technique, especially when you need coarse-grained "bucketized" prioritization.  MoSCoW is an acronym that stands for:

  • Must Have - These are the features that are mission critical for the success of the project.  When we create or update products, these are the products that will encapsulate the "Brand Promise" of the product.  For example, part of Basecamp's brand promise is, "It’s a place to share files, have discussions, collaborate on documents, assign tasks, and check due dates."  Those are the mission critical features of the program because they are encapsulated in all the marketing and communication associated with the project.
  • Should Have - These are the features that are not absolutely mission critical, but without them the product will look and feel "incomplete."  An example of "should have" features would be features that your competitor's products have, and that you know in order to reach feature parity you will need to have also.
  • Could Have - These are the features that are "on the fence", and have a 50/50 chance of making it into the release, based on time, scope, and budget.
  • Won't Have - These are features that will definitely not make it into the release, either because they are so undefined, the value proposition is unknown, or they are simply too "out there" to understand.  An example of a feature that should not

Prioritization forces a more rigorous thought process

Whether you're an engineering leader,  project manager or key stakeholder, its very easy to say "yes" to every new feature, especially if it means adding something to someone else's ever-growing list.  We try to push back, but the push back is in vain, because at the end of the day, we all want to deliver, make our projects a success, and make our stakeholders happy.  Every addition has a cost, and the easiest way to make the costs visible is to force rank a priority.  Imagine this scenario:

"Hey Pat Project Manager, this is Bob Business guy on the line, we have a new requirement that we need to put in.  1st quarter numbers depend on it"

"Hey Bob, I got your email about it last night and took it to the team to get estimated.  Looks like about 4 weeks of additional work.  We can do it, but we can't do that plus everything else on the plate, so let me know where it is in priority to everything else so we know where to slot it"

In this case Pat made the costs visible to Bob, and now its Bob's decision as to where this new item is in priority.  Without any priority, this conversation could never happen.  Now Bob is going to start asking deeper level questions of Pat and the team, such as "How much longer will the project take if we put in this feature?" or "What if I took out this other feature down here that's not so important, could we fit it in?" or maybe, "Can we do a slimmed down version of this feature I am asking for and still get it in."  Without understanding the cost, Bob can't prioritize.  Now that Bob understands the cost, he has a much better foundation to negotiate with the team and the PM.

Prioritization makes the best use of limited resources

There has never been a software project in the history of humanity that has ever had enough time, money, or people.  So projects have to get the most value from the resources we have on hand.  Prioritizing the features means that our business partners can help us understand whats more valuable and less valuable in the overall list.  This way, even if we don't finish every feature, we have focused our attention on the most valuable features.  We may not be able to release the fully fleshed out vision, but we can release an Minimum Viable Product, get customer feedback, and re-prioritize the list of outstanding features based on usage and what customers think.

This prioritization exercise is part of a game that everyone plays, because no one has perfect information.  The team best understands how much time a feature will take.  The stakeholders and product manager understand how valuable it is, and the PM or Scrum Master understands the impact on timeline and cost.  All three of these constituencies need to work together to negotiate priorities and scope in such a way that is transparent.

Prioritization is a form of risk management

Prioritization is a form of risk management.  The Project Management Institute reports in its 2015 Pulse Report, "64% of companies frequently use risk management techniques."  This is probably because when people think about risk management planning, they envision 3 ring binders full of documents of dubious value around risk mitigation plans and probabilities.  It doesn't have to be that way.

Prioritize your list of features, and that will give you a workable yet lightweight risk management plan.  One way prioritization helps manage risk is that it forces conversations around cost and value.  We always want to create the least costly yet highest value features of the product.  This minimizes product risk.  Another way prioritization helps with risk is that any gaps in information required to make a priority call become painfully obvious when we attempt to prioritize.  This minimizes knowledge risk.  Lastly, if something is a high priority yet the team has no idea how they are going to tackle it, getting the team the support they need minimizes the social and technical risk associated with the project.

Three techniques to help you prioritize

Prioritization by knowledge value

At the beginning of a project, what you don't know might hurt you.  Removing the unknowns is a huge opportunity to positively impact the health of the project over time.  In order to prioritize on knowledge value, we have to be willing to admit we don't have all the answers to the unknowns.  After we do that, we can prioritize some of the "knowledge value" items on the backlog, such as spikes and prototypes.

For projects that are risky, this is extremely helpful.  Why?  Because the opposite of risk is not analysis.  The opposite of risk is knowledge.  Since risk is defined as unknowns, the best way to reduce risk is to reduce unknowns, and you reduce unknowns with knowledge.

When do you know its time to prioritized by knowledge value?  Here are a few signals to help you understand when it's time to stop thinking about functionality and start thinking about risk reduction:

  • The team says, "We don't know if that will work..."
  • The product owner says, "I don't know how the customer will react to that"
  • The architect says, "I'm not sure if the platform will support this feature"
  • The business analyst says, "I haven't figured out the requirements for that part yet"
  • The tester says, "How will I test that?"

In each of those examples, there were clear signals that a lack of knowledge was preventing someone from having confidence to move forward.

Prioritization by increased revenue

This one is always a clear winner, but is heavily dependent on the sophistication of the product owner to be able to articulate the ROI associated with a feature or user story.  Therefore, this needs to be one of the items thought about when prioritizing.  An example of this would be payment options.  Here is an example:

"UX Mockups show 15% of people who are in the checkout process click on the paypal button.  Our cart abandonment rate is also 15%.  Implementing Paypal as payment option will significantly decrease our cart abandonment rate and lead to a 10%-15% increase in revenue"

How to calculate potential increased revenue for a feature

  1. Create a comparable benchmark against which to measure the current gap in revenue.
  2. Quantify the potential increase in revenue (either percentage or dollars)
  3. Compare the increased revenue (over 1 year) to the cost of creating the feature
  4. For all increased revenue related features, order them by decreasing increased revenue

Prioritization by  cost reduction

This is another one that is easy to articulate and easy to defend, but requires some research and number crunching to have a sound basis.  Cost reduction or reduction of "Total Cost of Ownership" is usually one of the driving forces behind new projects.  An example of cost reduction would be changing platforms:

"The old platform costs 10c per transaction, and the new platform costs 7c per transaction.  Moving the functionality to the new platform will save us 30% per transaction, and we do over 1 million transactions per month."

In the above example, the cost reduction was easy and straightforward to calculate.  Most of our real life situations are a bit more complex and messy.  Here are some helpful tips for calculating cost reduction for prioritization

Anything that reduces time indirectly reduces cost, such as automating manual tasks.  Investigate how much time your customers spend manually executing this task, and use a nominal "cost per hour" of this persons time to come up with a cost reduction figure.

Chopping out features can sometimes reduce costs.  An example of this is when a company comes out with a "lite" version of software with only the core features.  Fewer features = fewer support costs.

Creating an open API and allowing developers to create features can reduce costs.  This is because feature development shifts to the development community, which means independent developers will be responsible for funding and supporting the add-ons.

Wrap Up

For a lot of the companies I have worked with over the years, prioritization was one of the most difficult and painful lessons they needed to learn.  They had settled into a mode of everything being top priority, and as a result, they did not get the project outcomes they desired.  Their teams were demotivated, and people felt pressed into delivering sub-standard product.  Prioritization doesn't stop at the project level.  Some of the most successful companies I have worked with have used some of these same techniques to prioritize:

At the program level:  Effective prioritization can help with complex program management in that it can help make sense of complex inter dependencies between projects and programs.  While there is nothing that will remove the complexity, prioritization can help break it up into chunks and easier to plan and execute.

At the strategic level:  Effective prioritization helps align strategic priorities with tactical needs, resulting in an easy to understand and easy to communicate strategic plan that has a forced ranking of the different initiatives.  Strategic plans are often the result of a 2 day executive offsite, but often have nothing tangible that the individual contributors can wrap their arms around and really figure out "What are we doing this year?"

Taking the same value driven mindset at these higher levels had outsized impact on the people, project, and teams downstream.  It was easier to align everyone toward the mission, and there were fewer surprises when it came time to go live.

About the Author

Tirrell Payton is the Principal at Payton Consuling, a San Diego-based boutique firm that helps companies get more value from their technology teams.  Prior to starting Payton Consulting, Tirrell was a consultant in McKinsey's Digital Advisory practice

Rate this Article

Adoption
Style

BT