I am really new to prioritizing requirements in agile projects. What are the different aspects of prioritizing requirements in a traditional approach vs. an agile one?

  • After the edit, it's not too broad anymore, though it may be too opinion-based; I'm honestly unsure. I'll vote to re-open and we'll see what the community thinks.
    – Sarov
    Dec 28, 2017 at 14:23
  • Here is an article Agile vs Waterfall: Requirement Gathering. Perhaps this will help you get started. After that, if you have more specific questions, feel free to edit your question or ask another. Dec 28, 2017 at 14:26
  • 1
    Prioritizing requirements does not happen in many traditional (PMI-based) efforts; everything is simply in scope. Dec 29, 2017 at 20:57
  • Not so much of a difference. Requirements have attributes that apply in both cases and should be complete, consistent, unambiguous, prioritized, necessary, modifiable, traceable, etc. Prioritization should be a collaborative activity involving different stakeholders; when sorting, check the need, timing, costs, etc. MoSCoW is a prioritization scheme, search it. Also learn about Story Points, see pm.stackexchange.com/questions/4251/…
    – user21496
    Dec 30, 2017 at 1:46
  • It might also be useful to note that many traditional projects don't really rank requirements; they simply filter specifications in or out of the project. There are certainly prioritization techniques that are usable with any framework, but ordinal rankings are only required by Scrum AFAIK.
    – Todd A. Jacobs
    Jan 18, 2018 at 18:52

4 Answers 4


Differences in prioritizing requirements between Waterfall and Scrum

The predominant software development process before Agile appeared on the scene was the Waterfall process. Scrum is the most popular Agile process. I will try to list some key differences between Waterfall and Scrum, as I see them:

  1. Cost vs benefit trade off is a key aspect of Agile: In the agile process, the teams estimate story size in story points and this gives the Product Owner an opportunity to prioritize them knowing their relative cost. In Waterfall, rarely if ever, individual requirements are estimated. In any case, there is hardly any opportunity for a cost vs benefit trade off discussion.

  2. In Agile the requirements keep changing: In Waterfall, it is very hard to change requirements - you need to go through a painful change control process. Agile embraces changing requirements. As you can see in the Scrum Guide:

    The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

  3. In Waterfall the requirements are typically grouped into 3 or 4 buckets: Some people group them into High, Medium and Low, some others use the MoSCoW method. But in Agile all stories are listed in serial order. This helps the dev team to work their way down the list.

  4. Agile has a single authority for prioritizing: Agile names the Product Owner as the single authority for prioritizing. In Waterfall there is no such designated authority. It is often decision by committee.

  5. Many Agile teams use the notion of an MVP: Many Agile teams carve out a sub-set of requirements into an MVP (Minimum Viable Product). The MVP is often deployed to a sample user population to get early feedback.


No Canonical Answer

There is no truly canonical answer to this question. In general, how work is prioritized is specific to the business goals of the organization, mapping of work products to targeted release dates, and the dependencies of work packages. This is usually true whether the methodology is agile or not.

The Pragmatic View

Pragmatically, agile methodologies generally follow a queue-based or ordinal prioritization scheme where any given work stream has one (and only one) "priority #1" at any given time. This is in contrast to many traditional methodologies where strict ordering of priorities isn't enforced.

Non-agile projects typically use a schedule-based system based on management-defined delivery targets, and the schedules are frequently based on earned-value or net present value calculations. In the real world, this often results in many competing requirements all being undifferentiated "top priorities" for the business. However, your mileage may certainly vary.

Sample Techniques

Regardless of methodology, prioritization can use any number of techniques, largely limited by your organizational imagination. Some examples include:

Many techniques aren't inherently agile or non-agile. Some work well when used together, and most are designed to support the project planning process rather than serve in lieu of it. Again, your mileage may vary.


In order to prioritize tasks you need to know some techniques:

  1. MoSCoW
    Which are Must, Should, Could and Won't
  2. Minimal Marketable Features
    Features are decomposed into the smallest marketable units of useful deliverable business value, in order to fit within short iterations and ensure critical functionality which is implemented first
  3. Return on investment (ROI)
    Demonstrates how much return an organization makes by investing in percentage
  4. Internal Rate of Return
    A way of expressing profit as an interest rate earned.

And there are many others, but I think these are the most important.

But the customer usually does the prioritization.

The difference between Agile and the traditional approach is that in Agile the customer does the prioritization as he must see the result very soon, but in the traditional projects he sees the result at the end, so you do not need to care about the sequence of the tasks.


Technically Driven vs Value Driven

It's often true that in waterfall, requirements are simply in or out of scope, and the customer doesn't get anything until it's done. But the work is often still prioritized because it happens serially. In this case, the requirements can be prioritized purely from a technical perspective: looking at the entire project, what is the most efficient way to proceed? and/or what is the least risky way to proceed?

In Agile, prioritization is value-driven, and the incremental releases often go to the customer. While technical and risk considerations should be discussed with the customer so they can make informed choices, the customer-value prioritization typically won't look like the technically-sensible prioritization. So for example, it may often be the case that some minimal infrastructure is done early, to support relatively simple but highly valuable features; and that it is later torn out and replaced with a more robust infrastructure to support more complex but less valuable features.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.