Innovative thinking is the key to building great software—whether it’s a brand new product or the next release of an existing system. Done well, the agile practice of release planning provides a great opportunity to innovate. However, many software development teams—even agile software development teams—approach release planning in a way that actually discourages innovation. They are overly focused on figuring out the “right” work breakdown, and strive for an efficient process that merely “translates” requirements into user stories. Other teams get stuck in a kind of agile “analysis paralysis,” refusing to even start discussing stories until someone does sufficient up-front work and presents them with the “correct” product roadmap.
Either way, these teams are squandering a chance to innovate. Underlying both of these situations is an assumption that somebody has already come up with all of the right ideas—or at least that it is someone else’s job to do so. But innovation requires us to think of things that we haven’t yet thought of. And a well-run release planning activity is a perfect setting to focus the whole team on the process of idea generation.
Of course a planning exercise should ultimately produce some decisions. But we will get better decisions and better ultimate results if our planning process allows for and encourages creative, innovative thinking along the way. In other words, before we try to converge on a solution, plan, or set of priorities, we need to allow sufficient time and space to diverge. Teams often forget this step.
Stories as options
The principal tool for divergent thinking during release planning is the user story. A user story represents a small, independent, and testable piece of software. User stories are a useful tool for requirements discussions between technical and non-technical people, since they focus on what a user can do with the software. “Building a user story” means adding a bit of functionality to the product above and beyond what it already does. A release plan typically consists of a list of prioritized user stories, representing what we think we ought to build and in what order. By chunking the development work into these small user stories, we can build a little then evaluate, then build a little more and get additional feedback.
But user stories are not just a way to chunk work into bite-sized pieces. They are also a great way to generate and explore options. When we sit down to plan a release’s worth of work, we’re actually not looking for the right answer or the perfect schedule. We don’t want convergent thinking. Instead we are looking for options.
The most successful release planning sessions start with the explicit intention to go broad and to encourage divergent thinking. The more options we can generate, the better position we will be in to choose what to do next. And this is where brainstorming comes in.
Running a brainstorming exercise
Here’s one way to do a story brainstorming exercise. Gather a multi-disciplinary team together in a conference room with a big table. (Or gather a distributed team with videoconferencing and a multi-user collaboration tool like Trello.) Ensure that you’ve got people in the group with different styles of thinking and different strengths—both technical and non-technical. List the features under consideration on a whiteboard or a flipchart and discuss them briefly. Divide the group into clusters of 2-3 people, and pass out index cards and pens.
Ask each cluster to take 10 minutes to brainstorm as many stories as they can around a given feature or features. Explain that the goal is quantity and not quality. Don’t ask yourself things like:
- “What are the right user stories”
- “What is the correct way to build the feature”
- “What SHOULD we build?”
Instead, ask “divergent” questions like
- “What COULD we build?”
- “What are a couple of small stories we could build first around this feature?”
- “And if we built those, what could we build next?”
- “What are some other ways to tackle it?”
- “What other ideas for stories have we not thought of?”
Timeboxing this exercise is very useful for getting people out of an analysis mode and into a brainstorming mode. After the time expires for the initial brainstorming round, take the opportunity as a larger group to share and absorb what was produced. Here’s where the big table comes in handy, as you can collectively spread out and shuffle the index cards in different ways. Then do another round or rounds of brainstorming as desired.
Converge after you diverge
I prefer to see at least five times as many stories than we can possibly build come out of a brainstorming exercise. Because then we have options. We’re not constrained to one way of thinking about the problem or the solution.
You might be asking yourself, “How could we ever get anything done that way? We only have a limited amount of time to plan.” Starting with diverging doesn’t have to take a lot of time. You can hold a brainstorming session for 45 minutes and generate 100 stories. Then spend another half hour doing some high-level affinity estimation. In a little more than an hour, you’ve got a great set of raw materials from which to start.
With these raw materials in hand, then we can begin to converge on a solution, a set of priorities, and a plan. But even as we choose one way to start, we will continually remind ourselves that that there is something we haven’t yet thought of. By ensuring that we start our planning with divergent thinking, we’ll open ourselves up to more possibilities, and be more receptive when that next great idea hits.