We start every project with Inception, a discovery exercise that sets the scene for a project and produces an initial backlog. We hold an Agile Inception to kick off each new project, and on longer projects it’s common to “re-incept” at regular intervals (every 3 months, for example).
I love Inceptions because they demand everyone to find the threads that tie a product together. Sure, there’s no working software to speak of, but you get a clear sense of why you want to build something. I’ve run enough of these exercises to see some patterns emerge; as a company we’ve run so many that we’ve got the agenda down to a science.
Typically the process takes a full day, and attendance includes the entire product team (developers, product managers, designers, supporting analysts, product visionaries, etc.). A Pivotal moderator runs the show to help set expectations about how we work and to facilitate knowledge transfer between clients and Pivots. It all starts with…
Goals, Risks, and Anti-Goals
Identifying your goals sounds obvious at first, but it often surfaces very different objectives from team members. Rather than trying to prioritize, start by capturing everything identified and start to group themes for goals — company directives, value propositions, time-sensitive milestones, feature enablement. A common goal is to build [just] enough software to enable customer development and evaluation of a product’s viability.
A nice counter to goals is “anti-goals,” our term for capturing everything that might be important someday but presents a threat to achieving the immediate [self-described] goals. Ensure that every item in Anti-Goals belongs there, and everyone agrees (and knows why). This alone will save huge headaches when implementing features — if, for example, mobile-optimized layout is not a goal for an mvp, developers can spend less time building and testing that area of the app. More importantly, they know have more autonomy because they understand why they shouldn’t focus on mobile-optimization and have the context to later re-evaluate whether it’s still an anti-goal.
Risks are interesting because human intuition is often the best leading indicator for upcoming problems. These are captured by handing out cards to each team member, where they write down risks (one per card!). Some important risks to watch are:
- Business risks (Does the market want this? Will an emerging technology disrupt this product?
- Technical risks (Are there 3rd party integrations? Are there unknown technologies/libraries to learn? Does the product rely on platforms that are changing, e.g., iOS, Android?)
- Schedule risks (Are there pre-mvp phase gates to satisfy third-parties, e.g. developers on another team? Is there a near term, immovable milestone like a festival launch?)
When everyone is done writing, all the cards are collected and the facilitator starts to find themes here. Risks are critical to understanding prioritization and represent areas that need active mitigation. Pay attention to your risks throughout the project and make sure you can tick them off as you build.
Personas, Roles and Activities
This section could easily be a series of posts, so I’ll simply say that the group identifies all personas and roles that are important for delivering value and meeting goals. On a typical consumer content site, the important roles would be visitors (guests), members and editorial administrators.
WIth this in mind, start to capture the steps in the workflow of these users as the product delivers value. A Credit Rating app might allow a user to sign up, connect their credit cards, confirm their identity via SSN/address, and view their credit rating report. It might also allow a Sales Rep to identify members with low credit ratings and send them suggestions on how to improve their credit (or sell them another credit card).
Story Mapping
Now that we have the high-level flows, we start to capture the currency of an agile process: user stories. I’ve found that color-coding index cards acts as a visual guide for story creation. Pick a color (blue) and write “AS A MEMBER” — this is the placeholder for all of the relevant stories for members.
For each activity, the moderator leads the conversation on what stories make up the activity. In rapid succession, create cards of the same color for the story and place vertically under the role. If you mess up while scribing, rip up the card. There’s nothing worse than finding a story when you’re cleaning up…
The ideal granularity is Tracker-level; if requirements are too vague, coarser-grained is fine, but try to stick to the same granularity across all the stories. If it looks like there will be too many stories to get through:
- Prioritize the activities as High/Medium/Low, and write H/M/L on each
- Create stories for all Highs first, then Mediums, then Lows if there’s time
- It’s most important to get breadth across the app so that after the Inception the stories describe an application that’s useful, even if it’s not complete
For those dialing in, this activity is best suited for people in the same room. We have some stellar remote devs who should weigh in on tips to be a bigger part of this process, but it takes a lot of focus and discipline.
Estimation
Now that you have all of your stories, it’s time to give them estimates. While uncommon for the industry as a whole, we rely on developers to provide estimates for story complexity. Using the powers-of-two point scale (or Fibonacci if you must), create lanes for 1, 2, 4, and 8 points and “too big.”
Developers discuss stories and shift them into point lanes. The whole product team should be available to clarify questions. Once everyone feels confident that cards are estimated reasonably, write the point total in the lower right. Now that you have a point count for the project, you can discuss the project timeline given an estimated velocity of 10 points per pair per week (this is totally arbitrary, ymmv).
Prioritization
Once the stories are estimated, you can start to form a backlog by placing them in priority order. I like to call this The Home Edition of Pivotal Tracker. I expect the Product Manager to lead this activity, but I’ll often help by setting up a skeleton that makes sense in an agile development context. Refer back to goals and risks as you prioritize stories; are you leaving a bunch of 8-point stories to the end? Can you mitigate any risks by addressing the unknowns earlier? Can you identify compelling mini-releases within the backlog? A nice forcing-technique is drawing a line somewhere in the middle of the backlog and asking if everyone would be comfortable stopping there. Invariably cards will get pulled up and others pushed back as you introduce a premature end.
Deciding the order of the backlog
Once you feel good about backlog order, review it with the whole team. Take this opportunity to recap the day by telling the story of your project as it unfolds and ensure that you’ve addressed every goal (and most risks). Lastly, have a beer, you’re done!
About the Author
