From Strategy to Story

I often wind up with clients who are so fixated on keeping their teams working that they don’t have a clear strategy or vision that they can communicate. They lose themselves in the world of finding more work for the teams to consume. For the few that have a vision or a strategy, there is a considerable gap between that vision or strategy and the work that is happening.

Maybe someone, if they looked at it long enough, could figure out how their work tied back to some broader strategy, but it’s like solving a riddle. So the question to me becomes how do you provide that transparency and trace work from strategy to story.


Don’t read this article if you are going to get hung up in the land, of “That’s not agile!” If you believe the only world that exists is one that can’t include long-term ideas, then stop now. I’m writing for people who have long-term goals and work iteratively and incrementally toward them.


I believe that groups and teams benefit from long-term ideas and strategies. They want to build the best product in the world, have the best technology behind it, get paid the most, and so on. These aren’t short-term ideas.

So, at some point, someone will have to write down and communicate what these long term goals are. We can call it a roadmap, strategic intent, charter, whatever you want. What it isn’t is a commitment. It’s just writing down what the group believes to be significant over a longer time horizon.

I also don’t care how long of a time horizon they use. If you can think out ten years, go for it. Some people work better in planning backward from an ideal state. Some don’t.

What I’m looking for in this long-term plan is that it can explain it in about 5 minutes, and if someone saw it posted on a wall, they could make sense of it too.

Put some identifier next to each item also.


Now we have a long-term idea of what we’re about, let’s look a little closer, maybe over several quarters or a year.

Building the near-term is an exercise in planning in large chunks. Some people might say these are Epics. Others won’t. That isn’t the detail to worry about now.

The idea is to look at what you want to attempt in that near-term. Prioritize it with everyone who can override this decision.

For most organizations, this will happen at a management level. The main thing is that they have some larger goals that they want to work towards and they know the priority. Now, for each one, connect it back to the long-term plan with those identifiers.

Give each of these near-term items an identifier too.


Now is when we see the magic happens, if you’ve decided that those near-term items were epic-sized, that’s fine, and you’re ahead of the game. If not, continue breaking them down into pieces that are consumable by teams. Use those identifiers to tie it all back.

If you aren’t to continuous delivery or are having to plan releases, then you can use the near-term and now-is term to build releases.

At this point, people are probably getting nervous about how much planning is happening. None of this has been framed or is intended to be a commitment with a deadline. These elements are used to create alignment and give options.

For example, by looking at what could go into which release, you can then do some interesting scheduling and sequencing. If when planning your releases you realize that you are trying to release a ton of stuff near the holidays then you should take another look because it won’t happen. You get the options now and from now on to even out your scheduling so that it’s consistent with priority and not overwhelming for the teams.


Here’s where things get interesting. If you’ve built these elements in to be highly visible and transparent, you can create alignment throughout your groups.

Could you walk to any member of a development team and ask them how the work they’re doing ties to a strategic objective? No? There’s more work to be done. If they can, then you’ve just accomplished something very few companies have.

Pat yourself on the back, and move on to increase the transparency, frequency of feedback, and quality of decisions within those feedback cycles.