In the 'user story' approach to requirements, it is considered a good practice to write your story's objective in the form "As a user I would like to perform some action so that I can get some business value/benefit. For example "As an insurance claims processor I would like to flag duplicate claims as 'duplicate' so that I don't process and pay for the claim more than once."
If you are developing software in your typical enterprise, soon or later you will come to a point where your application has to integrate with some external system. Writing user stories in such a scenario can be quite challenging.
Ideally the business should be able to assign some dollar amount to the business value called out in the 'so that" phrase. It is critical to call out the benefits of having the systems communicate with each other and share data.
Let us consider this example:
"As a user of system Foo I would like to create a new account and the new account creation message should be broadcast over a message queue."
The above story objective describes the implementation details and it does not call out the business value in this story. This is a poor objective for a user story.
An improvement will be to identify which systems will be consuming this message. Here is what the modified story would look like.
"As a new user of system Foo I would like to create a new account and the new account creation message should be broadcast over a message queue so that the SAP application can be informed of the new account."
This was slightly better than the earlier version, however it still isn't easy to associate a dollar amount to the 'so that' portion of the story title. To get to the business value in this story we need to look at what the SAP system does with the new account message.
Here is a final version of the story
"As new user of system Foo I would like to create a new account and inform the SAP system of the new account so that the SAP system can create a corresponding account for the user and bill the user for the services provided."
When you define integration stories in this manner, firstly it clarifies the business value obtained by implementing the story and it also makes it easier to test the application end to end. The other desirable side effect of this is to allow the business analyst to talk purely in terms of the expectations of the business and let the developers (who are more qualified than Business analysts when it comes to implementation) find optimal ways to make this integration work.
It could be argued that the architecture demands System Foo not be aware of the nature of the consuming application, and by calling SAP out by name we might tempt the developers to violate this requirement. Such details are important and need to be part of the acceptance criteria of the story.
Photo licensed under creative commons, photograph credited to Roger Smith
2 comments:
Nice example. The problem is not restricted to integration projects. I saw the same issues extending existing systems, which is - by definition - what agile development teams do all the time. Users and developers have a tendency to anticipate solutions.
It's very important for future development of a user-story to have a clear goal of the business ("So that"): nobody enjoys developing useless features.
Besides that I find very important the role in the business who will clearly benefit from the feature to be developed ("As a"): The one who needs it is more empowered to provide details about limitations of the feature, etc. Can be made part of a communication plan.
For instance I will further adapt the user story to:
As billing representative I would like each new account creation on Foo to obtain automatically corresponding account on SAP so that I won't perform the sync operation each time I have to bill.
For me "User" is not really interested in appropriate bills to it's Foo account!
Post a Comment