Agile Requirements Prioritization In Action
The first time you try to add weight to requirements you may experience a lot of spin as everyone insists that either nothing or everything is important and is a must-have. Here is a simple, practical example to get people on the same planet, if not the same page: Button styling. Button styling may be very desirable for UIs in general, but is a very low priority for internal-facing applications.
Other requirements prioritization examples include:
- Web developers who prioritize their project requirements by doing page layouts first and then lower-priority details later can adjust faster.
- JavaBean developers can create the retrieval methods before the sorting methods as sorting can be passed on to the presentation layer if the back end work gets backed up.
- Creating a functional navigation first and refining it to an intelligently flexible navigation later can save time if the delivery date arrives and only the current functionality is ready. Starting with flexible navigation first could leave many requirements unfulfilled as the delivery date approaches.
Adapt Agile or Waterfall Process to Your Environment
While I explained how Waterfall projects can benefit from one (and more) Agile approaches in this article, I am not implying that one process is always superior to another. Waterfall works under one illusion: everything in a software project can be planned and executed according to that plan. However, Agile has its own illusion: business stakeholders will be involved throughout the software development lifecycle. I have participated in many Agile projects where business stakeholders didn't appear at 99% the daily stand ups; everyone was surprised the 1% of the time when they did show up.
The goal should be to know how to adapt these processes to provide the maximum value possible within a given environment rather than how closely the environment can be modified to match the process.