Why Use Process Stories for Agile Software Requirements

With the rise of agile methodologies in software development, there has been a notable shift in project planning, analysis, and design processes. Agile's emphasis on flexibility and speed can sometimes lead to insufficient upfront planning and a lack of in-depth analysis or comprehensive design. 

This situation often puts technically skilled developers in a challenging position, as they may lack clear and detailed guidance on the specific needs and expectations of business users. They then have to do analysis and design of business requirements on the fly. Analysis and design is not necessarily what a developer is best at. 

The root of this issue isn’t a shortfall in the developers' abilities, but rather a gap in the methodologies used to collect and articulate the business requirements. This calls for an approach that not only accommodates the agile framework's strengths but also addresses its limitations in capturing detailed, user-centric requirements for software development.

Many attempts have been made to define a methodology for defining what the business user actually needs. This usually comes as a business case, requirements document, or user story. 

While business cases are important from a business standpoint, they define the why for what an organization is doing. They are for businesses that are expending resources and need to justify why they are doing what they are doing. This is not what developers and product people need to develop a good product. They need a clear definition of what needs to be done.

One way that people define what needs to be done is a bunch of requirement statements. These are loosely organized sets of statements defining what needs to be done from only a high level perspective. It doesn’t specify which user needs to do what which is a critical detail to understand who does what. Requirement statements are often conceptual and non-action orient, so they need to be broken down into specific activities before software can be designed to comprehensively accommodate them. These statements also often get mixed with the purpose or why these requirements exist which unnecessarily complicates the clarity of the requirements and leads to the requirements becoming overly large.

Another way to define who does what is a user story. This is an organized set of activities a single user can performs in the software. This is a great way to keep focused on what the business user actually needs. However, it doesn’t factor in how the users interact with each other. This is a vital part of designing any system that user stories skip over.

A process story is an organized sequence of business activities performed by many users. Unlike requirement statements and user stories, it offers a comprehensive view of the entire process, detailing who does what. This holistic approach provides a clear, actionable guide for designing software that clearly articulates the business needs.

A process story is a series of activities describing actors doing actions. This describes who does what when in an organization. For example:

When Customer submits order, Company automatically records order information.

|------------ Condition ------------|   |- Actor -|  |-------------------- Action --------------------|

Customer Service Representative records Customer name, phone number, and Address.

|----------------- Actor -----------------|  |------------------------------- Action -------------------------------|

I’ve found that using process stories in the development workflow is the most useful way to plan high quality software.