Deciding what (and how much) behavior you want is the hardest part of the entire story creation process.
The reason for this is straightforward—if it were an obvious decision, you wouldn’t even have to consciously think about it. Your brain would make the decision for you unconsciously, and the story definition would simply flow out on its own.
In contrast, if you’re actively thinking through a decision, it’s because there are positive and negative tradeoffs associated with each option. It’s better to be intentional than unintentional about accepting the tradeoffs.
I have often seen people freeze up at this point. Without one option that’s clearly better than the rest, we reach decision paralysis. And it’s extremely uncomfortable.
Below are several guidelines I follow to break the paralysis.
This is part of a series about creating Agile stories; so far, I’ve spoken to slicing-and-dicing a set of stories, authoring story content, and defining a story goal. This post contains guidelines for the hardest part of all: making decisions.
1. Decouple Components and Behavior
One common way people get snarled up is in what I call “dependence hell.”
For example, say we’re authoring a story to show a list of times when a building is open and closed. Here are some of the thoughts that might run through your head if you’re thinking about this:
- “Ok, I need to get the list from the database.”
- “All right, I have a database–but how does the list get into the database?”
- “I know that this list should come from the administrator’s management screen.”
- “But I don’t have that screen yet, so I need to build that as part of the story, as well.”
- “And then the list should also go from the interface to another system. But that interface isn’t built yet.”
- “Oh, and in order to use that interface, I need to upgrade our communications library.”
- “And upgrading that library will break our other systems communication.”
- “All of that just to say I can’t show the list on the screen because I depend on these four other features.”
- “So, how do I decide where to start?”
The answer here is to look for places where behavior can be decoupled. We need to show a list on screen. As long as it’s in the database, we don’t care where it comes from. Our story list might then look like this:
- Show the list of building times hand-entered into the database.
- Create the management interfaces to edit the list of building times.
- Upgrade our communications library to maintain compatibility across multiple systems.
- Add the systems integration to pull the list of building times from another system.
Dependences are hard. And scary. But they’re manageable when taken piece-by-piece.
2. Break the Batch
There is another benefit to decoupling behavior beyond defining stories: It provides more flexibility to deliver incremental improvements over time.
- It may very well be that we can get by with the hand coded-list for the next six months.
- Then, in six months, we can introduce the edit screens.
- Finally, we can introduce the systems integration when we truly need it to scale three years from now.
3. Think in Terms of First Draft, Second Draft, Third Draft…
In contrast to being stuck in dependence hell, I’ve also seen people experience decision paralysis when they cannot see the perfect outcome.
- Is it better for a UI widget to be one screen or another?
- Should selecting a value in Widget A auto-select another value in Widget B?
- How exactly should this widget behave under these twelve different circumstances?
Sometimes the complexity or number of permutations is just too much to think through in one sitting. So instead of going directly from nothing to final copy, I prefer to think in terms of drafts.
The first implementation is like the first draft—I get the widgets on screen and start tinkering with them. Are they working well together? Does an experience feel clunky? What behavior feels right in a modern application vs. feeling awkward or outdated?
Now that my first draft is done and I’ve played with the system, I can author another story that I consider the second draft. Apply the learnings from the experimentation to making this draft even better.
Most features will be working pretty well after two to three attempts.
Thinking in terms of drafts helps implementors stop thinking that everything must be precisely defined before you start. And drafts help story authors avoid feeling stuck when they can’t predict or decide on every micro-behavior upfront.
4. Just Pick Something Already
This suggestion is perhaps the most effective, and it’s also the most anticlimactic—just pick something.
Are you faced with two options, each with their own positive and negative tradeoffs? Which one do you pick? Whatever. There’s a good chance that, in the long run, it doesn’t matter. We’ll eventually get all the needed features in place, regardless of when they’re implemented.
My experience is that some people—especially those with engineering backgrounds—are unconsciously, ruthlessly optimizing everything. But sometimes that optimum< feels impossible to compute.
So don’t try. Just pick something already and get started instead of picking nothing and accomplishing nothing.
Conclusion
Making decisions is often the hardest thing we need to do day-to-day. In many cases, it’s more of an art than a science. And that’s okay. We’ll figure it all out as a team.
I hope the above guidelines, as well as this entire series on creating Agile stories, has been helpful!
This is the 4th in a series on writing Agile stories: