Turbo-charge Requirements Elicitation for features & user privileges.

One of the most common things I have to do on software development or Application selection projects, at one point or another, is to define a series of potential features or functions. They can range from obvious and nearly mandatory (e.g. ‘reset password’) to the more ‘out there’ features. Often, trying to get stakeholders to contribute to the production of these feature sets (note: they are not requirements yet!) is a pain in the proverbial backside. Everyone is too busy to tell you what they want their shiny new toy to do – although they’ll be quick enough to tell you if you get it wrong!

So, over many years & many projects, I have developed (and continue to develop) a quick and easy process to get the obvious features into a list early in the engagement _ but in a way that cries out for stakeholders to get stuck in and evolve it. Feel free to adapt it to your needs – you can use it to impress stakeholders with your speed of delivery!

I begin with a spreadsheet. Column A is for the features, defined almost as if they were orders or instructions (e.g. ‘reset my password’). Each column after that represents a different User Type. For example, Customer, Driver & Vendor. At each intersection of feature & user type, I add an ‘X’ if that user type should have that feature. I tend to get a bit carried away but usually remember to limit myself. It’s very easy to end up with over a hundred cells with an ‘X’ in them… without even thinking about it. That many rows & Xs will only scare stakeholders away resulting in TL:DR (“Too Long: Didn’t Read”).

It might be easier to understand what I mean if you can see it rather than just read about it… I’ve uploaded a contrived example to illustrate:

https://app.box.com/s/nqjtaul9oykwm6vu9qzh5tgmkww1u2ji

If you open the file linked here, you will see that the first column defines the features (one per row) and three subsequent columns are for three different user types. Wherever a user might potentially have access to a given feature, I add an ‘X’. I then add a formula in a separate worksheet (but have added it in cell F3 for this contrived example) that automatically generates a User Story (for Agile projects) or a conventional requirement for waterfall projects. The formula for the contrived (Agile) example looks like this:

=IF(B3=”x”, CONCATENATE(“As a “, B$2, ” I want to “, $A3), “”)

I then copy this down the rows of a column per user type. It immediately and automatically generates User Stories in the generic Agile format. More importantly, as you add and remove privileges for different user types, it adds & removes user stories automatically. You can see an example in this screenshot:

https://app.box.com/s/2dmmfmaykyy553k3ant83wk3dtqonu4h

Once the stakeholders get hold of the spreadsheet, they generally understand it very, very quickly and I then let them add their own rows (features). Eventually, I gather them, merge them and then convene a session to review and finalise.

Eventually, I export the spreadsheets as CSV files and, with a tiny bit of find-and-replace, I have a few hundred user stories in a CSV format that can be easily imported into Jira (for example). These then become the test suite for the UAT phase and, since they’re in a simple spreadsheet, they’re easy to read & manage.
In a more mature environment, where stakeholders are accustomed to this methodology, I sometimes mix it up by adding a priority row to the spreadsheet. Each stakeholder adds a 1 to 10 value. I average these values when I merge the returned spreadsheets and I end up with a first-pass at a prioritized backlog and a guaranteed discussion-starter when stakeholders are (finally) able to get together.