As a followup to an excellent article by my colleague Marcus-Requirements-Building the foundation strong. ,In the Agile scheme of things,it becomes almost a necessity that requirements are well-defined and with enough information to prioritize and do iteration planning.One guideline that is often repeated to measure the requirement is
- What is the business value of implementing this requirement?
Some of the examples are
- Improves usability of the application
- Will make the application faster
- Adding this feature will make a workflow X easier to use.
On face value ,this makes perfect sense.I mean why do it if it’s not positively impacting a valuable feature in the application or not providing a valuable feedback,but if not used correctly this can often lead to dropping of important non-business facing requirements.Some of the examples of requirements which normally don’t pass the business value test is
- Change the architecture
- Technological changes that impacts the long term roadmap of application
- Internal products such as metrics dashboard
To summarize,at any given time,it’s important to keep things in perspective and make sure that seemingly non-business value tasks are in fact important stories in life-cycle of the product.
