Don’t lose track of the big picture

Categories Agile

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where–” said Alice.

“Then it doesn’t matter which way you go,” said the Cat.

Alice’s Adventures in Wonderland, Lewis Carrol 1865

One of the most important things Scrum sets out to do is to increase our chance of building the right thing. We deliver working software in short sprints and make sure we get frequent feedback from our customers and/or users to see that we’re on the right track. If it turns out we’re not, we correct the course and adjust our product backlog.

That’s all well and good, but is it enough?

If we’re not careful, we risk focusing too much on getting our heads down and completing as much work as we can. If we don’t have a clear vision for what we’re trying to achieve, the danger is we might end up just a “bunch of stuff”. Albeit very efficiently.

Further, if our innovation only happens within the sprints, we also limit how innovative we can make the product. There is, after all, very much a limit to how ground-breaking our ideas can be if we also need to implement them, all within just a couple of weeks.

Product development requires us to see the big picture

Perhaps surprisingly to some, the Scrum framework doesn’t tell you anything about how to handle the product vision or strategy. Look for either of those in the Scrum Guide and you will find nothing.

However, for a product owner who is responsible for maximising the value of the product, they are essential.

Even, or particularly, in Scrum, we need to know what we are doing and why:

  • Product vision why are we doing what we’re doing?
  • Product strategy – what is the path to achieving our vision?
  • Roadmap – how do we implement the strategy?

Without these in place, the risk is that we just get too bogged down in the day-to-day, tactical delivery. We end up making small, incremental improvements that make things slightly better but fail to create that awesome product.

Product vision

The product vision answers why we’re doing what we are doing. A couple of examples:

  • Ikea: “To create a better everyday life for the many people”
  • Spotify: “Give people access to all the music they want all the time – in a completely legal & accessible way

Admittedly, these are corporate visions rather than product visions, but I like them nevertheless. They show how a good vision is short and memorable.

Product strategy

The strategy describes the path to reaching the product vision:

  • Who are we targeting?
  • What problem is our product solving for them? What benefits does it give them?
  • What is our product and how does it stand out from the competition?
  • What are the business goals of the product?

One way to formulate this strategy can be to use a Lean Canvas as template.

In contrast to the product vision, which is unlikely to change, the product strategy can and should be updated as we learn more about the product through the experiments and features we deliver in our sprints.

It can even turn out that our strategy is completely wrong and we need to replace it with something different. The sooner we find that out, the better!

Product roadmap

The roadmap describes the major steps we’re aiming to take to achieve our product strategy. 12 months is a typical timeframe as it is hard to try to predict too far into the future what we will be doing. After all, the product strategy (and the roadmap, obviously) may change as we learn more.

A roadmap should focus on the big picture and not contain too much detail. A too granular roadmap would not only waste our time but also risk locking down what we’re doing, too soon. If we say we will deliver the such-and-such widget in February, someone might assume that means we will! A roadmap needs to evolve as we learn more.

Therefore, it is a good idea to base the roadmap on bigger themes or goals. What are the main outcomes we’re aiming to achieve and how?

For example, for each of the next four quarters, list in a grid:

  • The overarching goal for the quarter, e.g. “increase the number of users”.
  • The main features, on a high level, e.g. “30 day free trial, simplified user registration, social media integration”
  • How we know if the goal has been met, e.g. “10,000 new active users”

A nice template for a roadmap like this is can be Roman Pichler’s GO Roadmap.

Involve the team and stakeholders in creating the roadmap

A roadmap is not of much use if it only lives inside the head of the product owner. It needs to be seen and talked about.

If the product owner drip-feeds work to the team, with no visibility of the roadmap, how would the team be able to make sure that they tackle their work in a way that aligns with the roadmap?

It would also be a mistake not to involve the team and stakeholders in the creation of the roadmap. We would not only miss out on the insights they could have contributed to make the product better. It would also make it much harder to get people’s buy-in into the roadmap later.

One useful exercise when creating the roadmap can be to identify the goals and key deliverables through Impact Mapping. This can also help us make sure that everything we add to the roadmap fits with the product strategy.

Where does the product backlog fit?

Finally, for completeness, where does the product backlog sit in all this?

The product backlog is the prioritised list of what the team will be (or could be – we don’t have to complete everything in the backlog). This also includes bugs that need fixing, as we need to be able to say whether fixing a particular bug is more important than completing some feature.

The top items in the backlog are very granular, so that they can be completed within a sprint. Items further down are bigger and will need to be broken down before we can work on them.

The items in the backlog should deliver the goals in the roadmap. Chances are there will also be some things for which it isn’t clear how they contribute to the goal. That should make us ask whether we should be doing them at all. Yet another reason to make sure everyone is familiar with the roadmap!


The product vision explains why our product exists and the product strategy describes the path to getting there. Based on these, we create a roadmap which describes the major steps, or goals, we need to take over ne next 12 months as we work to implement the strategy.

Together, they help us deliver a better, more focused product by preventing us from geting lost in all the detail in the backlog.


Magnus Dahlgren – Scrum Master (CSP) and Agile Coach