• Have you been in a situation where everything gets prioritized as MUST HAVE?
• Have you been in a situation where you have find it difficult to get different stake holders to agree on relative priority of different features?
• Most of the time is spent in discussiing low value features?
• Whoever screams the loudest, gets their pet features prioritixed high?
• Do you want to learn some more prioritization games/techniques that can be used to start prioritizing at Feature level and subsequently refine it to story level?
• You feel the current technique(s) you use for prioritization are time consuming and ineffective?

If answer to any of the above questions is yes, this is the workshop for you to attend

Why Prioritization?

Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product. In reality, customer expectations are high, timelines are short, and resources are limited. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions. Thus, requirement prioritization is used in Software development for determining which requirements of the software product/application should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first.

Several methods for assessing a prioritization of software requirements exist. In this workshop we are going show some of techniques/games we have used for feature prioritization.

"We want to be Agile!!...

Why?

Because its cool, and its becoming a norm, it will help us to cope with changing requirements, help us deliver faster etc etc."

Isn't this a common sentiment in organizations struggling with the ever changing user/customer taste?

With Agile going main-stream with most organizations looking to have at least a few business critical projects run in an Agile way, the question of ROI comes up. Shifting from a traditional way of building software to an Agile way, requires change and as any good business leader would know; change is not free. Business leaders would like to understand and justify the return on Investment to make this shift. In our talk, we will be talking about how to look at the Agile process holistically and how this process affects budgeting and how early value realization can help offset the cost of change. We will also discuss stories of other in house IT shops and product houses who have made this shift and the journey they have undertaken

From our experience of working with such organizations, we have found that for these process-focused Agile adopters, much of their measurements include:

- how long is our stand-up?

- how long is our build?

- how many stories do we have?

- how many points can we fit into a sprint? etc.

From their perspective, they already have plenty of metrics. Often it's also the case that they're getting benefit, just because common sense does kick in behind the scenes, and because they're delivering more frequently as a result in the reduction of documentation, so they don't always run out of money either. That leads to bad habits, possibly, rewarding wrong practices. In this talk we want to discuss metrics we have used on the projects and have found useful. Metrics like: Cycle Time, Time to market (also called Lead Time), Collaboration, Quality (in terms of code complexity , code coverage, test pyramid) and bus factor. One thing to note is that any of these metrics alone would not provide holistic way of measuring benefit, and hence a combination of them is required.

"We want to be Agile!!...

Why?

Because its cool, and its becoming a norm, it will help us to cope with changing requirements, help us deliver faster etc etc."

Isn't this a common sentiment in organizations struggling with the ever changing user/customer taste?

With Agile going main-stream with most organizations looking to have at least a few business critical projects run in an Agile way, the question of ROI comes up. Shifting from a traditional way of building software to an Agile way, requires change and as any good business leader would know; change is not free. Business leaders would like to understand and justify the return on Investment to make this shift. In our talk, we will be talking about how to look at the Agile process holistically and how this process affects budgeting and how early value realization can help offset the cost of change. We will also discuss stories of other in house IT shops and product houses who have made this shift and the journey they have undertaken

From our experience of working with such organizations, we have found that for these process-focused Agile adopters, much of their measurements include:

- how long is our stand-up?

- how long is our build?

- how many stories do we have?

- how many points can we fit into a sprint? etc.

From their perspective, they already have plenty of metrics. Often it's also the case that they're getting benefit, just because common sense does kick in behind the scenes, and because they're delivering more frequently as a result in the reduction of documentation, so they don't always run out of money either. That leads to bad habits, possibly, rewarding wrong practices. In this talk we want to discuss metrics we have used on the projects and have found useful. Metrics like: Cycle Time, Time to market (also called Lead Time), Collaboration, Quality (in terms of code complexity , code coverage, test pyramid) and bus factor. One thing to note is that any of these metrics alone would not provide holistic way of measuring benefit, and hence a combination of them is required.

MVP is defined as : "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."It doesn't say a thing about the product being valuable to the customers or market segment.

MVP is minimum viable product *NOT*  minimally marketable feature set / first release!  MVPs are the experiments we learned from on the way to our first release of the software.

To us the core of the difference between "Minimally Viable Product" and "Minimally Marketable Product" is in the purpose.  An MVP's purpose is to learn, an MMP's purpose is to serve.  Understand the problem vs address the problem.

• Have you been in a situation where everything gets prioritized as MUST HAVE?
• Have you been in a situation where you have find it difficult to get different stake holders to agree on relative priority of different features?
• Most of the time is spent in discussiing low value features?
• Whoever screams the loudest, gets their pet features prioritixed high?
• Do you want to learn some more prioritization games/techniques that can be used to start prioritizing at Feature level and subsequently refine it to story level?
• You feel the current technique(s) you use for prioritization are time consuming and ineffective?

If answer to any of the above questions is yes, this is the workshop for you to attend

Why Prioritization?

Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product. In reality, customer expectations are high, timelines are short, and resources are limited. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions. Thus, requirement prioritization is used in Software development for determining which requirements of the software product/application should be included in a certain release. Requirements are also prioritized to minimize risk during development so that the most important or high risk requirements are implemented first.

Several methods for assessing a prioritization of software requirements exist. In this workshop we are going show some of techniques/games we have used for feature prioritization.