We recently wrote about the realities of user stories in large organizations trying to shift from traditional business process requirements practices to Agile. Simply put, they just don’t work. Projects are too complex. Business stakeholders and Business Analysts don’t know how to write them. And traditional practices are so deeply embedded.
Here’s the reality: Most of the people responsible for business process requirements
- Are new to Agile,
- Don’t know how to write user stories, and
- Live daily in Microsoft Office.
On the other hand, most development teams
- Use Agile techniques every day to do their work,
- Need user stories to derive tasks and tests, and
- Live daily in an Agile task management tool, like JIRA.
Many organizations get “stuck” in their Agile transitions, because no matter how hard they try, they’re still unable to reconcile these differences between traditional and Agile worlds and the people who live in them. So how do they get “unstuck” and kick their Agile transition back into gear?
Business Process Models can bridge that gap.
Why? In many ways business process models and user stories are similar. They’re both used to describe requirements. They both represent a journey from an end user’s perspective. And they both provide information to developers and testers that they need to do their work.
But business process models are also:
- Familiar to all. Both business and technology professionals use them all the time to visualize business and technology, inform decisions, and improve processes. Business process models are written in a shared language.
- Visual. The best practice of visualization – the use of models, like process flows, mockups, and prototypes – boosts collaboration, improves understanding, and leads to more complete requirements than text alone. Everyone engages to develop a shared understanding.
- Flexible. Business process models can be used to describe high-level and more detailed processes from both user and system perspectives. They can be inter-related to represent the hierarchies of processes and sub-processes. They can be augmented with text and color-coded to add information. Their variations are virtually endless, yet they are still intuitively understandable.
- Simple to construct. People have been using Microsoft Office and Visio for decades to create process models. And most modern requirements tools that support visualization, including Blueprint, use similar, simple, drag-and-drop interfaces for diagraming processes.
User Stories come to life when paired with a Business Process Model.
In many ways, a business process model, with its multiple steps and pathways, represents a collection of individual user stories.
- Its roles translate to a user story’s who – the person, role, or system performing an action.
- Its tasks translate to a user story’s what – the action or goal of the user story.
- A user story’s why can be derived from downstream tasks or the outcome of the process.
- Pre-conditions, post-conditions, and system responses translate to a user story’s acceptance criteria.
With a set of well-written, hierarchical business process models representing end user journeys, teams can easily analyze and decompose processes into individual user stories fit for consumption by the development team. The user stories also end up being of higher quality, because they’re:
- Connected to a bigger picture. They connect high-level business processes to lower-level development tasks. The development team can see user stories in context, which leads to a better understanding. The upstream and downstream traceability also enables improved impact analysis and change management.
- Influenced by a broader community. Visualization engages people, so business and technical stakeholders are more likely to get involved. The shared language of process flows enables everyone to review requirements and provide feedback. It’s less likely that key stakeholders or valuable corporate knowledge will be missed.
- Easier to write. The information needed to write user stories is contained in a set of familiar visual models people can easily understand and convert to well-written Agile requirements artifacts. business process models also provide a framework for organizing them.
- Easier to understand. Business people can reference process models to better understand how user stories were derived. Technical people have more information from which to draw on when creating and managing their work tasks. Over time, everyone becomes more familiar with the construct of the user stories and how they fuel the development team.
If your business stakeholders and Business Analysts are struggling to write good user stories, change your frame of reference. By deriving user stories from well-written business process models, people begin to speak the same language. There’s power in that pairing.
For more information on how Blueprint enables the business process model-to-user story connection, contact us today.
