Thanks so much, Sebastien.

There are 4 themes of how pre-sprint research and framing have altered the sprints we run.

1. Kickoff

You’ll have some artifacts from framing (+research) that you’ll take into the understand stage of a sprint; e.g. user interviews / JTBD interviews, proto-persona, ICE matrix, vision / context map(s), experience map. These provide much more context and visualization of the challenge you’re tackling in the sprint.

Some of the info should be shared prior to the sprint, so people have a foundation before entering the room. Then, the person kicking off the sprint will use these to align the sprint team on the problem in front of them. Let the team review them and ask questions, but for the sake of time, I tend to avoid long discussions or edits — if anything capture challenges, new ideas, etc in a parking lot.

2. Goal

I use OKRs to initiate strategic discussions with companies about which themes they’re interested in working on for the quarter / year. Because of that, I have a strategic objective that should guide the problems we consider and the solutions we sprint on. We also have key results that will help measure our success. In addition, with framing we have a very clear problem statement.

All of that is to say that I’ve been struggling to justify an additional goal at the sprint level. I’m curious if others have felt the same or have ideas to share?

3. Map

The biggest change is the mapping portion. Since you already have a map from framing that you’ll share during kickoff, you won’t be creating 1 in the sprint. I typically have a digital version of the map that we can explore, zoom in/out on, and review — I use Mural for that. But then I also print out a large (8' x 8') paper version so that the team can still interact with it, iterate after expert interviews, and stick HMWs on.

Again, I don’t suggest inviting the team to redo the map, but small discussions and edits are fine.

4. Timing

Because of all of this pre-sprint work, the understand phase is much more informed, visual, and engaging. That translates into a more efficient team which results in less overall time needed for the sprint.

My sprints look like this:

• Day 1: Understand, Ideate, Decide (up to storyboard)
• Day 2: Prototype
• Day 3: Test

Was this helpful?

Since I get this question a lot, I’ve been planning to write a full post about this topic. If I missed anything or there are additional ideas people have / want me to cover, share your comments so I can consider them for a post in the future.