We have now decided that we need to write user stories. The begs the questions as to who our users are. When I first started thinking about our users I originally came up with three or four users. I believe this is very typical when people start with user stories. They pick the obvious users and then create their stories around them. In doing this we miss many requirements.

I decided to do some brainstorming using a mind map. With this mind map I wanted to explore the users of our product. What you see below is 15 minutes of one person doing the mind map (me).

Our Users

Wow there are many more than 4 users. I am sure there are more users if more of us were working on the mind map. (I actually thought of several other users since I did this map.)  When you start evaluating these users you realize that there are many requirements that can be derived from each user. Of course you may see roles that an user enacts that be combined with other other roles to streamline the number of users.

My premise is that every requirement can be derived from a specific user role. Even the technical requirements have a user.

So as you start creating user stories,  brainstorm as to who all of your users are. When you do this you will be able to derive a rich set of user stories that will cover the majority of your requirements. If you find a missing requirement it is my premise that a specific user role was missed.

Today I ran accross an excellent book, 97 Things Every Software Architect Should Know, 1st Edition. I highly recommend this book. It is easy reading but one of those books filled with axioms that we need to reminded of all of the time.

The first maxim is “Don’t Put Your Resume Ahead of the Requirements”. How often do we want to use a new technology because it will look good on our resume?

There are 96 more to go. You may disagree with what these experts are saying but they are thought provoking. Take a look at this book.