Tool to auto-generate User Stories with minimal typing and even less repetition…

• This is an update of an earlier post that I published back in December 2015 (actually, precisely 6 years ago today..!). I’ve updated it to take into account some things I’ve learned since then, and expanded it to include instructions on auto-generating User Stories in the Connextra format, to allow direct importing into Jira and automatic [optional] linking to any pre-existing Epic. I’ve included a downloadable template to get Business Analysts and Product Owners started. The tool is ideal for Business & Customer stakeholder engagement when identifying features and as a tool to facilitate Dev & QA stakeholders’ decomposition of features into bite-sized chunks. There’s even a tip (feedback from a User) on adapting it for anyone in the Project Manager or Coordinator role.

One of the earliest activities carried out in the product & software development lifecycle, and one that then reoccurs regularly throughout the development process, is to define a series of potential features or functions (i.e. ‘”requirements”) and then break them down for estimation, prioritisation, development and testing.

Requirements can range from the obvious and near-ubiquitous (e.g. ‘reset password‘) to the more ‘out there’, but still valid for capturing & documenting (‘split a NFT so it can be shared like a real, physical object‘).

They can range from the very granular and detailed (‘submit username and password in landing page to login to account‘) to the very abstract & aspirational (‘move through a metaverse‘).

Often, trying to get stakeholders to actively contribute to the production of these requirements 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! Read on to find out how to make this task more productive, more interactive (and iterative) and less painful.

Over many years & many projects as a Lecturer, Agile Coach & Transformation consultant, Business Analyst, Product Owner & Product Manager, I have been involved in countless requirements’ elicitation and elaboration sessions involving stakeholders from the very highest level of organisational demand:

• Board Members & Executives;
• Politicians, Elected Representatives, Bureaucrats and Administrators;
• Senior functional managers;

…to the very lowest level of granular Technical expertise:

• Technical Architects & Platform Owners;
• Agile and non-Agile Software Developers;
• QA, UAT and BAT specialists;

Over that time, I have developed (and continue to develop) a quick and easy tool that allows participants to focus on eliciting requirements early in the stakeholder engagement process & as often as necessary throughout the elaboration & development lifecycle, but in a way that encourages stakeholder participation and doesn’t disrupt the natural flow of a free-form stakeholder engagement session (such as a requirements workshop).

The template is available to download here and tips for using it follow below. Feel free to share this post and the template: anything that makes requirements elicitation more effective & efficient should be widely shared. Feel free to adapt it to your needs.. you can use it to impress stakeholders with your magic!

It begins with a spreadsheet (as most things seem to!). Column A is for the features, written almost as if they were orders or instructions (e.g. ‘reset password’). This is known as an “imperative” tense and you should start all requirements with this form, because the template will add the who (and the why, if that’s your thing) automatically.

Each column after that represents a different user type. For example, unregistered Visitor, Customer, Admin or System. At each intersection of feature & user type, add an ‘X’ if that user type should have that feature.

You might find that you get a bit carried away. It’s very easy to end up with over a hundred cells with an ‘X’ in them… without even thinking about it. If that’s the number of (potential) requirements that have been elicited in a session, then great: that’s a seriously useful artefact to trigger ongoing refinement, discussion and prioritisation.

If each of those requirements was written in text form, it would take much, much longer and most participants in requirements’ elicitation sessions will get fidgety, bored and frustrated while waiting for them to be written up. They will probably subsequently scare other stakeholders away, resulting in a TL:DR (“Too Long: Didn’t Read“) approach to requirements validation. Reviewing a box of Xs is much easier than reading hundreds of lines of (often very similar) text, so you get what you need and your participants thank you for making it painless. Very clever…

To the Jira, everyone…

Finally, you will want to import all your new requirements into Jira. There are a variety of articles on the Wibbly Wobbly Web that will help you with this, so it will not be covered in detail here. Two points are worth highlighting, however:

1. Jira imports work on the basis of the Headings in a CSV (i.e. whatever is in the first row). This is why the headings in each column of the ‘UserStory’ tab in the template are ‘Summary‘ and ‘Epic Link‘. Jira will import the text into those fields. The only mandatory field in an import is the Summary.
2. You can, if you wish (but not during a requirements’ elicitation session!), add more fields to your Jira import (e.g. an import CSV can include text for ‘Comment’, ‘Description’, ‘Label’ etc). However, it’s probably best to start simple, with the ‘Summary‘ (and ‘Epic Link’ if the Epic already exists) and work towards something more comprehensive over time. It is important to remember that the template is designed for speed & simplicity when eliciting, documenting and discussing requirements.

Once the initial set of requirements have been captured as a series of imperatives and Xs in the matrix, and User Stories generated in the ‘UserStory’ tab, you’ll note that there are a bunch of empty rows. These are the cells that don’t have an ‘X’ in them.

On a side note, these empty cells can actually be quite useful, as they can be used to generate a set of constraints. For example, you can have a User Story that states:

As a customer I want to login to my account

…and this is represented by an ‘X’ but the absence of an ‘X’ for Users of type non-Customer could be used to derive (for example) acceptance criteria.

As a non-Customer I can't login to my account

This will not be discussed in this Blog post (just to keep it simple) but the more intrepid among you will be able to extend the Excel template and the Jira import CSV to do this. Or you can contact me directly if you are really interested in learning how to do it…!

So, the next step is to use Excel’s built-in capabilities to obscure the empty cells. In the ‘UserStory’ tab, select the first column (click the column name). Then click the dropdown beside the column name – it looks like this:

Then unselect the last entry, called ‘Blanks’. You will see that the column now only includes cells with content. Select all of the cells, including the one that has ‘Summary, Epic Link‘ but excluding the column name. Once selected, copy the selection and then paste it into your favourite text editor (tip: use notepad or notepad++, not Excel or Word, to avoid formatting and file type issues). Repeat this process for each column in the ‘UserStory’ tab. If you’re appending each column below the other in a single CSV, you don’t need to copy the ‘Summary, Epic Link‘ cell each time. It only needs to appears once as the first row of a Jira import CSV.

So, in summary:

1. Filter out blanks from the column(s) in ‘UserStory’ tab.
2. Copy and Paste the content (but not column name) into a text file.
3. Repeat for each subsequent column.
4. Save the text file and then follow the Jira instructions to import from CSV.

It might be easier to understand the process if you can see it and do a walkthrough using your own requirements, rather than just reading about it… download the template, put some imperatives in column A of the ‘matrix’ tab and then look at what’s generated in the ‘UserStory’ tab. It should be self-explanatory.

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

Just remember: every ‘X’ you add will result in a User Story being added to Jira so take some care in configuring the columns to suit your needs before starting (i.e. you may not have multiple User Types!). Having said that, I have always believed that every potential requirement should be captured, even if it is then discarded.

…better to have it and not need it, than to need it and not have it…

…and on we go…

Once stakeholders get hold of the spreadsheet, they generally understand it very, very quickly. You can then comfortably let them add their own rows (features) or even give them a copy of the template with the first tab empty. This is a great way to allow stakeholders to gather at a time that suits them and populate their requirements in a way that is easy to share and discuss.

In a more mature environment, where stakeholders are accustomed to this methodology, I sometimes mix it up by sending the populated spreadsheet to stakeholders (those who participated and those who didn’t) but with a priority column added to the spreadsheet. Each stakeholder adds a 1 to 10 value. I merge & average these values (using Excel vlookup across multiple spreadsheets, if necessary) 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. The priority value can even be included in a Jira import CSV (suitably rounded up to whatever priority rankings are configured in your Jira instance). This helps with understanding what Business & Customer-facing stakeholders consider important.

Variations on a theme…

You can Start with Epics rather than User Stories. In the very earliest stages of discovery for a potential Product, Business and Customer-facing stakeholders might only have a general idea what they want (‘We need a Customer profile section and an online shop with ordering and payments‘). This can lead to a series of Epic-sized requirements. However, don’t try to force a size parameter here. Just allow the stakeholders to tease out what they think they need, whether that is at the 10,000 foot view or right down at the Ux level (‘Customers will want to add items to a basket in one click‘). Just add a row and one or more Xs. After all, an Epic can have only one Story…

Then – perhaps while stakeholders are having a break – take one or more Epics & add them to Jira, simply to get an Epic ID (import them in bulk if there are lots), before breaking them down into Stories in the second half, this time with the Epic ID included… instant Backlog in Jira with minimal typing!

Remember, the whole point of requirements’ elicitation is to understand what the Business considers valuable. In addition, the fundamental principle promoted by a Lean approach to work is to minimise the effort required to maximise the output (i.e. maximise the things not done). This little tool will allow valuable resources (i.e. peoples’ time) to be used in the most effective way… and minimise manual documentation without losing anything valuable, which is always a good thing!

For the Project Managers among us…

Another use for the template, which I found out from feedback sent by earlier users of the template I published in 2015, is to use it to generate an Actions List, created and shared by those in a Project Manager role.

Instead of core Story functions in column A and User types in subsequent columns, one reader had ‘actions’ for rows and ‘owners’ for columns. After a minor change to the Formula in the ‘UserStory’ tab, they auto-generate a list of actions & owners from any meeting in seconds, even where there are multiple owners. This was then shared as the ‘minutes’ of the meeting, with Attendees, Actions and Owners auto-output into a text document, by typing a few Xs..!

Another enterprising reader created a template for auto-generating a RACI matrix on the fly in all Project meetings. That’s clever, because it allowed for a text-based document (required for auditing purposes) to be auto-generated in real time after any significant change of personnel or responsibilities.

What next…?

If you adapt the template here for any other use, or if you have any other point to make on it, please feel free to comment…