User stories are a powerful way to enable requirements that are at once understandable by both the user community and the people who will develop the IT systems. They can be a powerful tool for the analyst to build that elusive bridge between the business and IT. At once user stories have to be supported by the business user community, and directly enable IT people to develop associated code, architecture, and/or integrations.
User stories are important, and to get the most from them, it is helpful to recognize the inter-relationship of user roles to the desired capabilities to the targeted system features. It is helpful to recognize the connection and interplay between these Agile constructs. The more complex the business challenge, the more important and helpful it is to start the development of user stories with this agile context in mind. There will probably not be a concise and consistent alignment across them at first, but it is suggested (for the sake of value, productivity, etc.), that it should be developed in the background by the analyst. On a practical basis, the alignment is strengthened iteratively (you will experience a productive give-and-take across them), so keep this context in mind all along the way. In the end this simple structure will have helped everybody.
Regulatory compliance promotes control and auditability in accordance with standards and performance expectations. This places considerable focus on the relevant processes. The threat of losing business opportunity or being fined results in the business taking these particular processes quite seriously. Processes associated with regulatory compliance tend to be relatively current, well documented, and be more proactively supported.
Certainly this is good for the interests of compliance and consequently the business and assumedly the public at large. However, there are additional business performance benefits that can be derived – essentially nice by-products that positively influence other aspects of the business.
Companies that are subjected to regulatory compliance find themselves becoming process savvy beyond the domain of regulatory compliance. They sometimes demonstrate behavioral norms that reflect success they have attained with regulated processes. This could be, for example, recognizing that “processes are not the enemy” or becoming more generally accepting that they do provide value, or bringing process improvement ideas forward. Similarly, regulatory success might spawn internal process teams or gurus capable of productively addressing diverse process needs.
Crossing organizational boundaries often presents a stiff challenge to process development and execution efforts. Compliance is usually cross-functional by nature, and the visibility and diligence with which these process activities are addressed can open up new dialogue and levels of cooperation and understanding. Compliance process work sets a precedent that can translate to better teaming on other important matters.
Compliance is significantly data-driven. Again, diligence applied to support the data needs of compliance can have positive implications for the enterprise. Compliance data can be the path finder into master data management.
If the opportunity presents itself, it is advisable to capitalize on positive developments that can come from regulatory compliance. Do you really have a choice?