Summary
Neither of your current user stories will work. This isn't simply a result of writing the stories incorrectly; it's a direct result of a non-agile approach to large systems development.
Below, I describe what user stories are and aren't. I also discuss other tools that may complement your user stories, especially in regards to providing additional scope and context. And finally, I provide some recommendations for making your systems development process more flexible through emergent design, and better able to embrace complexity through iterative development.
User Stories are Not Specifications or Requirements
User stories are many things:
- Conversation starters.
- A starting point for customer collaboration.
- Deliberately high-level feature descriptions or acceptance criteria.
- Brief (even shorthand) use cases that describe a value proposition and a value consumer.
One thing they are not, however, is a technical specification or detailed requirement document. No less an expert on user stories than Mike Cohn has explicitly stated that user stories are not specifications.
While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.
Use More Appropriate Tools
Depending on what you're trying to express, other tools and artifacts are often more effective than user stories in defining specific elements for your product. Many of them can be used in conjunction with user stories.
A Product Backlog holds features to be developed, but leave the implementation details to collaboration between the development team and users. Workflows are generally captured with user story mapping or user journeys. Acceptance criteria are often best expressed through Cucumber features. You might even have other project artifacts that hold additional detail about functional and non-functional requirements.
"Agile" doesn't require you to try to stuff all of the details of your product into user stories. Stories are just one tool (among many) for meeting the values and principles of agility.
Analyzing Your Use Case
Write one story something like AS AN administrator I WANT to set parameters SO THAT downstream activities follow the correct path. I would need to attach a flowchart to the story.
This is only partially correct. The administrator is not the value consumer, so you want to identify the user who will take the UX journey, use the feature, or gain the benefit. That way, the team can collaborate with them or their chosen proxy. In addition, such a story is not inherently testable. While attaching (or referring to) a flow chart is certainly a useful thing to do, such a vague story won't provide sufficient context to develop a test-first solution.
Your other alternative is worse:
write one story for each configuration of parameters and then what I want to happen downstream for each.
This attempts to shoehorn detailed specifications into each story. While possibly testable, this type of approach overly constrains the solution space to the point where you lose most of the benefits of an agile approach.
You are essentially taking a whole-systems, "big upfront planning" approach to your design and implementation. This is inherently non-agile, and the unwieldiness of this approach is contributing to the awkward stories you're finding on the backlog.
Choosing between too-big epics and overly-details specification documents is a false dichotomy. Neither is the right choice. A more agile, just-in-time design approach along with iterative development will resolve most of the problems you're currently describing.
Recommendations
First, accept that agile frameworks are both incremental and iterative. You don't have to design and implement the whole system all at once. Instead, you build up the system piece by piece. This often results in refactoring and rework as the team collaborates with the customer on what's actually needed, rather than simply on what's been asked for in the beginning. This is a fundamental mind-shift that must take place for a project to be agile, and for it to succeed.
Second, foster collaboration. A user story should describe a vertical slice of functionality that serves as a conversation starter between the development team and the users. For example, a good user story might be:
As an HR administrator,
I want the system to automatically reject all resumes
so that I don't have to print them out and circular-file each one manually.
This story describes a value consumer that the team can collaborate with to validate acceptance criteria and feature fit (the HR admin). It also describes a feature without overly constraining the solution space; it says what is wanted, rather than how it will be implemented by the system. And finally, it provides context that helps the development team craft a solution that not only meets the goal, but that can also guide implementation choices to better fit into the user's workflow.
Iterating and Refactoring
In a big system, there will be many of these types of stories. Each iteration should deliver an increment of potentially-shippable functionality. However, when the system is extremely large or complex, later stories may require changes or modifications to the system to accommodate the new features without breaking the old ones. This is an expected aspect of agile projects.
This "emergent design" is handled by refactoring (changing implementation details without impacting behavior), or by accepting that there will be additional work involved in updating aspects of the system. As an example, let's suppose that some future bit of work says:
As a compliance officer
I want all incoming documents to be saved for 7 years
so that regulators can never find their needles in our haystacks.
Maybe the HR admin's story was implemented with a "reject and delete" approach, because the team didn't yet have this new context in scope. So, the team may need to refactor the HR functionality to reject-and-store as part of this new compliance story, and that level-of-effort would be factored into the new story's estimate during iteration planning. Or perhaps the new story can't be implemented without changing something more fundamental about the system. In that case, the fundamental changes are analyzed, decomposed, and put on the Product Backlog just like any other work for the project.
Agile frameworks embrace change. Incremental/iterative development, refactoring, and rework are inherent to the agile approach. By providing transparency within the Product Backlog, you may reduce unnecessary rework by consolidating related items together so that any conflicting context or workflow differences can be spotted more easily, but you'll never eliminate rework entirely. Accept the benefits of agility (such as the ability to deliver small, complete slices of functionality quickly), and treat refactoring and rework as a basic cost of doing business this way.
