Traditional project management approaches of describing all requirements in lengthy documents give people false assurances that they’ve considered everything. Agile focuses on minds and businesses on delivering real value.
With Agile, we plan iterations every two to four weeks, each time identifying the requirements which will deliver the most value and pushing these higher up the list of priorities. Those bringing least value are pushed to the bottom of the queue.
Value For Users
When writing requirements it’s easy to describe simply what you want:
“Implement social media links on all product pages.”
But why do this? What use is it to the user? How will they benefit?
Requirements under Agile are described as user stories. A user story focuses the requirement on the end-user with a description of the value being delivered. A typical structure is:
“As a [type of user], I want [something], so that [value achieved].”
Which, for example, might translate as:
“As a customer, I want the option to automatically post interesting products on my Facebook page, so I can share them with my friends who are interested in the same things.”
In this case, we describe who the user is, what function they want to perform and why that matters — this is the value will be delivered.
Traditional approaches don’t force those writing the requirements to identify the value. But if a requirement is delivering no value, why waste money delivering it at all?
Value For Business
When we focus on value to the business and our customers and prioritise requirements by their value, the product we develop will quickly become usable, because all the highest value items will be delivered early in the project.
Buying an off-the-shelf solution can seem the obvious simple choice, but you often pay for functionality that isn’t necessary and doesn’t add value. It also limits you from being able to develop new value in future.
By delivering iteratively and choosing requirements wisely, the resulting product is very lean. This provides an excellent platform on which to build, adding in more functionality and options over time as you understand more about your product and how it’s being used. It can evolve based on real user feedback and real experience.
Asking Why
No matter how big or small a requirement is, be sure to question it, to understand the reasons behind it — the Why — so that you’re equipped with the knowledge to make your decisions.
Including a few small ‘shiny’ features that only look good and don’t deliver real value could distract from developing a piece of functionality that would revolutionise how your users carry out their job.
Base your requirements on a real understanding of what your users need rather than a hunch or personal preferences — genuine research and testing is important and should be done on a regular basis.
Focusing on the ‘Why’ will deliver better value for your users, which in turn creates better value for your organisation.