Agile, Requirements

A System User Story Holy War? On a Saturday night? :)

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:

  1. To examine the full behaviour of the Application/System to confirm that the design and concept is full fleshed-out and complete.
  2. To create a light-weight model to capture the Application/System behaviour for communication through out the team.
  3. 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

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: