I’ve struggled for a while with the concept of System User Stories. I know about the debate and argument that about only User Stories should be used to measure progress. And I agree 100%. I am not proposing that these System User Stories would be used to manage the project and measure progress, but that they would be used to validate and confirm the system design and completeness of User Stories. In essence, they don’t remove the need for User Stories but are an additional activity and deliverable. I also feel they are an invaluable light weight model that documents System behaviour. I feel the lack of Application or System definition between User Stories and Test Cases and Code is just too broad of a gap. There is room for a light weight model to fill that gap and ensure our solution has a high level of completeness and cohesion.
In my definition, these System User Stories are stories that define how the system components are interacting with each other at a high level. They have been attractive for me for primarily three purposes:
- To examine the full behaviour of the Application/System to confirm that the design and concept is full fleshed-out and complete.
- To create a light-weight model to capture the Application/System behaviour for communication through out the team.
- To confirm that we have the appropriate User Stories and tests across the entire Application/System.
One thing that has always troubled me about User Stories is that unless there an end-to-end light weight model of the System, we may have the system architecture and design affected when User Stories are worked on in later iterations if the functionality starts to diverge from previous understanding. Having a light weight model of System User Stories that we can then validate Traditional User Stories again greatly reduces this risk and highlights any areas not covered. I think the System User Stories have more value for complex systems. I am currently working on a very complex system, and I feel System User Stories were essential to ensure our design and scope was complete, correct, and compelling. Since the project is somewhat R&D we also lack a Traditional Product Owner so this task falls on the project team. System User Stories helps us to clarify this concept.
So given the fact that I think they are required, what format do they take?
What I have found to work is that they should be in total no more than 2-3 pages in total. Any more than that and you are going too deep and not just confirming overall design and consistency. You are actually doing requirement definition.
I also like the User Story type of format. It is complete and concise. The format I have used is:
As an [Domain Specific Language Component] I will [do a Domain Specific Language Action] when [Event] using [Domain Specific Language Components or System Components]
The Domain Specific Language Components and Actions can be anything from true DSL Components or Actions to just the abstraction to the high level components used in the System or Application. It definitely should not be at a low-level. I also have broken these System User Stories into major features just for easy categorization and organization.
And then finally I renamed these System User Stories as System Grammar. I did this to shy away from the System User Story holy way and also to reflect that these rules truly are the grammar that the system uses to build its language of functionality.
System Grammar. I think there is a place for it.
Re-posted from http://bornagainagilist.wordpress.com