In agile development, a feature is a chunk of functionality that delivers and supports business value. Features can include additions or changes to existing functionality and can be business or technical driven. For planning purposes, the A2F Framework also use the notion of "work items" that can include features, bug fixes, stories, and other artifacts. But features are the main unit of Big Room Planning. Ideally, a feature should adhere to the following criteria:

  • It should provide business value or support business value.
  • It should be estimable - it must have enough definition for the development team to provide an estimate of the work involved in implementing it.
  • It should be small enough to fit within a Program Portfolio timebox - therefore, if it is too big, it should be broken down further.
  • It should be testable - you should understand what automated or manual test a feature should pass in order to be acceptable to the customer.

Features should be validated to ensure it fits into a Program Portfolio Timebox, which can range from one to three months depending on the cadence of Big Room Planning. Once the Features are created from the Progressive Elaboration process, validated as referenced above, and placed into the Feature Backlog, the next step is to prioritize or re-prioritize the backlog. There are different techniques to prioritize based on the level of stakeholder engagement. A2F Framework focuses on two popular techniques.


Prioritization Using Cost of Delay, Institution Knowledge, & Complexity

Cost of Delay is described by Don Reinertsen as being the "one thing" to quantify. "We need Cost of Delay to evaluate the cost of queues, the value of excess capacity, the benefit of smaller batch sizes and the value of variability reduction. Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organization."

Cost of Delay (CoD) is the economic impact of a value delivery delay. In other words, it is how much you will fail to make if the product, or feature, is not ready on a certain date. The benefit of using it is to be able to make more informed and better decisions because you're taking into account the economic impact. The A2F Framework uses its own Cost of Delay formula based on the 3 parameters as shown below.

The Cost of Delay analysis will help Product Managers do an initial prioritization of the Feature Backlog based on Monetary Value, Competitor Advantage, and Quality/User Experience Improvement. To utilize this technique, the Product Managers will use a normal 1 to 10 scale to identify a Feature with an estimated score of 1 for each of the three categories to use as a baseline. For example, Feature X can have a score of 1 for Monetary Value, Feature Y can have a score of 1 for Competitor Advantage, and Feature Z can have a score of 1 for Quality/User Experience Improvement. A score of 1 indicates that it has the least importance for that category however, it is possible the same Feature will have a score of 1 for all three categories. Once a baseline has been established other Features can then be compared to the baseline and given a relative score. For example, Feature A has 5 times more Business Value than Feature X, and therefore receives a score of 5. Once a Feature is scored in each of the three columns, then all scores are totaled for an overall score. The Feature with the highest overall score would be given the highest priority in the backlog based on CoD. To further prioritize, the Product Manager will consider institution knowledge and Feature complexity estimate to re-prioritize. In some situations, it better to implement Features that are more complex earlier than smaller ones even if the CoD is the same because this helps to mitigate risk. In other scenarios, its vice versa.


Prioritization Using the "Buy a Feature" Design Game

First, let's talk about why you would use a game to choose your product's features: (For our purposes, features are the aspects of a product that you would list on the packaging.)

To start with, you don't want to waste your time and resources building that something nobody wants. The choice of features to add to a release can mean the difference between a product that finds a market and one that does not.

In our other product development webinars, we have emphasized talking directly to customers; interviewing and observing them individually to get direct feedback about their needs and goals, however sometimes it takes listening to-and perhaps negotiating with-others before people form thoughts and opinions of their own.

The Buy a Feature design game bridges the gap between interviews and group exercises. This game directs a group of about 4 to 7 people to recognize their own needs and priorities, and then work together to compromise and negotiate those priorities with each other in order to finally settle on what is most important.
In order to play, create a list of about 30 potential features - these features can result from user and market research, or have been suggested by users, or may even be something your competition has.

Assign each of those features a "price"; the price is usually based on hard and soft development costs, but you can include other considerations such as the regulatory environment, your branding requirements, and possible ecological or social impacts.

Some features will naturally have a very high cost to them, while others will naturally have a very low cost.

After you've decided the cost for each feature, create an index card for each one, describing the feature and listing it's cost. This will make it easier for players to sort the cards.

Give each player an allotment of currency or scrip which they can use to buy the features they want most. Give them enough that they can buy the features they need, but only enough to buy between a half and a third of the features, because you want them to consider carefully which features they value most. Because some of the features have very high prices, players will be forced in some cases to pool their resources to buy especially important or expensive features. This motivates players to negotiate with others about the features they feel are most important.

Whether you're playing Buy a Feature in person with your customers, or via an online platform, you'll want some way of tracking your players motivations for selecting the features that they do. With an online game platform, players use an in-game chat to discuss their reasoning and negotiate. The chat will have some valuable insights into what your customers really want. If you're playing in person, you can act as a "shopkeeper", helping to clarify players' understanding of each feature, taking payment for each purchase, and asking players exactly why they wanted a feature enough to buy it.

Analyze the results of the Buy a Feature game in order to identify trends.

You'll want to know: Who purchased what? How much did they bid? Who negotiated with whom? What did they say? How did they shape the features?

If you aren't confident in information that resulted from one run of the Buy a Feature game, you can always run the game several times to identify emergent trends!

Below is an example of the Buy Feature game in action.


Definition of Ready

The Definition of Ready (DoR) is a list of criteria used to determine when a Story or Feature "Ready". A Story is ready to be pulled into a Sprint Commitment. A Feature is ready to be broken down into Stories. Below is our Definition of Ready at the Story and Feature level:


  • Acceptance criteria has been discussed with the team and is updated. All field-level validations, mock-up screens, etc. have been added to the associated stories.
  • No dependency on other Team Backlog items. Stories pulled into sprints should not have outstanding dependencies on other stories unless the dependencies will be resolved in the same sprint.
  • User Stories have been written in accordance with the INVEST* model.
  • Performance Criteria documented (if applicable).
  • Backlog Owner has prepared and prioritized stories in the Team Backlog for at least two sprints.
  • No critical open questions.
  • Compliance met and defined.
  • Assumptions are validated.
  • External dependencies must be resolved.


  • Business and Technical Features have been prioritized.
  • Feature Title, Descriptions and Acceptance Criteria has been defined.
  • Supporting Business and Technical designs.
  • Relative T-shirt size.
  • Business Value.