Introducing User Stories, an easy mechanism to capture stakeholder needs and requirements.
The Basics of User Stories
There are many forms a user story can take but I introduce a simple one here in the video below.
To sum it up quickly
As <someone> I want to <do something> in order to <achieve value>
Its an easy mechanism we can use to focus users into creating a basic form of requirement.
A practical example
Lets take a look at some basic examples.
- As a customer CxO I want to outsource my website management in order to reduce risk of unexpected maintenance costs
- As a customer CxO I want to outsource my website management in order to reduce operational costs
- As a customer end user I want to have an uninterrupted service experience in order to reduce wasted time
- As the web service product manager I want to have efficient operations in order to maintain a 30% margin
- As the web service product manager I want to have a completely automated deployment of my core services in order to be scalable
- As the web service product manager I want to have a completely automated deployment of my core services in order to reduce the chance of manual error
- As the web service product manager I want to have a completely automated deployment of my core services in order to have fast deployment times
Above are some typical examples that might come up in a planning session with product management. I could easily go to my stakeholders in separate meetings, and work with them to build a more complete list.
Turning this into ArchiMate
Is fairly easy. Again I showed it in the video but I will demonstrate. I don’t normally insist architects create a view like the one below but it has advantages if you are trying to extract value. Take a look.
I’ve done this quickly. Note I slightly changed the wording for both values and requirements – this is because we have to remember they are elements in a model. This means they need to be able to stand as independently and tell a story by themselves.
Viewing them this way means makes it easier to see which requirements yield the most value, and makes it easier for us to tie things together. We could use these user stories as a motivation view in our work planning.
You can of course also use this very basic motivation view as the basis for a requirements realization.
You could also use the work to group together values.
I will be talking a lot more about requirements of different kinds and approaches to them. Its a big subject – needless to say, User stories offer an easy way to get started capturing the needs of stakeholders.