Traditional companies tend to go into a black hole, brainstorm, and then come up with a bloated list of requirements for the product engineering teams to develop. With Agile becoming the new paradigm for software development, these processes are changing to engaging your customer more often and earlier in the software development life cycle (SDLC). If you want your organization to be competitive in the marketplace, you have to deliver on what the market wants.

Delivering on what the market wants is about delivering business value. Business value is not about delivering on schedule and within budget, but rather features for a product that the customer will use and love.

So, how do we help ensure product success for the market – well continue reading and find out!

Waterfall versus Agile

In Waterfall, requirements drive cost and schedule, but in the Agile paradigm, cost and schedule drives prioritized features:

So, how do we determine which features to deliver and when?

Ideation (Initiatives) to Product

Features are the result of your product vision, input from stakeholders, synthesis of ideas into themes, and collaborative discussions with your engineering teams. Stakeholder feedback can be your competition, customer, regulations and standards, sales, management, engineering, etc. Below is an ideation funnel that depicts stakeholder’s input to create a product.

The ideas that flow into the funnel are usually at the Portfolio level. This level is where your marketing, sales, executive folks are and they like to act as a think tank and solicit feedback from the market for future releases of your product. I am sure some of you know that these ideas can be completely off the wall and not aligned with reality. This is where you need a representative steering committee that also has technical understanding of the product to analyze these ideas to filter out the bad ones. This process is widely supported in the Scaled Agile Framework (SAFe). After you shortlist your ideas, you would want to do a read out with the different Programs to figure out which program is appropriate to turn your ideas into reality. Each Program will have either product management team or chief product owner. They will own the program level vision and roadmap. With that said, when they break down the ideas into Themes and Features, these will be your release milestones on your product roadmap.

There several techniques to help your team figure out features to do first. The two most popular and the ones I like are Relative Value and Buy Feature.

Let’s talk about the Relative Value Game:

Relative value is essentially giving a two dimensional scoring to your features. One score is based on complexity, risk, and unknowns as compared to one another. For example, if you have one feature that has more complexity, risk, and unknowns then another feature, then it will get a higher score. The other score is based on business value as compared to one in another. Again, if you have one feature that has more business value then another feature, then it will get a higher score. The actual scoring can be based on a scale like the Fibonacci scale. Then you can arbitrary group your features into one of 4 quadrants.

Based on your results, you want to focus on high business value, high risk first followed, by high business value, low risk, and then low business value, low risk. Features that are low business value, high risk, you want to eliminate from your release. But remember, technical dependencies will affect the order of feature implementation.

Let’s talk about the Buy Feature Game

The Buy Feature game is considered serious gaming because it has a significant impact on your business and our customer. The concept is very simple and fun, you allocate monopoly money to your invited stakeholders. You can give more money to certain stakeholders if they have more stake than others from outcome of the game. You can also allocate money based on a percentage.

To play the game, create a list of potential features and provide each with a price. Just like for a real product, the price should be based on rough development costs for each feature. Therefore, you need to have your teams t-short size the efforts of the features before playing the game. Then, customers buy features that they want in the next release of your product using play money you give them. Make certain that some features are priced high enough that no one customer can buy them. Encourage customers to pool their money to buy especially important and/or expensive features. This will help motivate negotiations between customers as to which features are most important.

This game works best with four to seven customers in a group, so that you can create more opportunities for customers to pool their money through negotiating. The Buy a Feature game is based on the list of features that are likely to be in your development road map.

Conclusion

In summary, understand the flow of how an idea becomes a set of features and how those features are further broken down into user stories and tasks and worked on during your sprints. Understand how you product vision and roadmap can give input on what set of features you have to work on for release. And that those features can be further prioritized by the techniques I described above. The are several games and techniques out there. If you interested in learning more serious gaming techniques for prioritizing features based on business value, make sure you check out innovation games (http://www.innovationgames.com/) by Luke Hohmann. The image below helps to illustrate the feature flow.

Remember, Agile is about delivering what you customer wants and including them in every step of the way for your release. Good Luck And Have Fun!!!