Prioritizing requirements in traditional vs. agile projects

Question

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?

Answer 1

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.

Answer 2

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:

• Relative Weighting
• Critical Path
• Vanhoucke, M. & Demeulemeester, E. L. (2003). The application of project scheduling techniques in a real-life environment. Project Management Journal, 34(1), 30–42.

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.

Answer 3

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.

Answer 4

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.