You are planning a software project, or working with Atomic to Research, Design, and Plan one. You’ve thought about your users, created context scenarios, and drawn up a huge list of features you’d love to have. But how do you prioritize that list?
- track a product’s features
- understand how features depend on each other
- prioritize features
- plan the sequence of feature implementation
At this point in the process, we describe features at a high level. We’ll flesh out the details later as we create the software.
Interactions & Stories
When we outline all the things a product will do, we break them into interactions and stories.
- Interactions describe larger tasks with a several steps but no precise workflow.
- Stories describe specific things a user will be able to accomplish with the software (also called features).
In general, every interaction is made up of several stories. “Create and manage a customer account” would be an interaction, while “request notifications” would be one of the stories that comprise it.
Stories can be written to fit a specific pattern:
As [a type of user]
I want to [do something]
So that [valuable achievement X happens]
As a customer
I want to request user notifications
So that I receive emails when my payments are due
Constructing a Story Map
As we come up with interactions and stories, we start to arrange them on a Story Map. We can make a physical Story Map on a large sheet of paper or whiteboard with sticky notes representing individual interactions and features. Or we can make a digital version that can be shared between the client’s and our locations.
Interactions are listed at the top, arranged left to right chronologically as they describe a user’s interaction with the product. Imagine we’re developing software to track a cat’s whereabouts when it’s outside. The product consists of a tracker that the cat wears on its collar and a mobile app that syncs with the tracker and maps the cat’s peregrinations.
Interactions for the tracker we would be:
- Track cat movements
- Sync with mobile app
- Indicate when battery is low
Interactions for the mobile app would be:
- Set up cat tracker system
- Sync with tracker
- Review cat’s movements
- Analyze cat’s emotions
- Share with other cat owners
For each of these interactions, we list the software’s related stories/features. For instance, under “Sets up cat tracker system” we might have:
- Set up cat tracker system
- App introduction with cat animation
- User creates account
- User enters information about cat
- User pairs tracker with app
- Sync account with cloud
Then we organize features — top to bottom — by priority, grouping them into major releases. The initial product release should include the minimum set of features that the product needs to be useful and successful. This release might simply be an internal alpha release that’s used for initial product verification, or it could be the first release that’s rolled out to a wider audience. Other features that add increasing value to the product are grouped together to as future releases.
In our cat tracker example, we might group our features like this:
- Release 1.0: user creates account, user pairs tracker with app, sync user account with cloud
- Release 2.0: app introduction with cat animation
- Release 3.0: user enters information about cat
Where does the Story Map take us?
At the time that we create the Story Map, we have a general sense of how complex features are, and thus we can start to estimate the effort that will be required to implement them, particularly relative all other product features. This allows us to estimate the length of time required to implement each software release.
This Story Map gives us a way to structure and time feature implementation. Major releases might occur every 1-3 months during the course of product implementation. Features come to life as we work towards each release in 1 week sprints, creating internal builds to be reviewed by the client with each iteration. Release milestones help us to maintain momentum and have fixed points where we can reconnect with the app’s users and validate our work.
Of course, the Story Map may change during the course of implementation. As we release the software to users, we validate assumptions that we made during planning and learn more about how the software is being used. Sometimes our assumptions are proved to be incorrect and we must adapt the software plan to account for new learning, perhaps adding or removing features or adjusting the timing of their implementation. As we complete each release, we revisit the Story Map and make any necessary adjustments.