Altitude Mapping
Altitude Mapping – Mapping the Product from Vision to Product Increment is a visualisation of the flow of information, output and activities when defining and developing a product. It covers everything from the Product Vision, through Epics, Roadmaps, User Stories and Tasks, Design and the Product increment itself.
The original concept is from Alistair Cockburn and Jeff Patton for use in creating use cases and story mapping. When I had the pleasure of working with Agile Coach Matthew Dodwell, we took their original concept and expanded it for use as a way of visualising the whole Product Development journey.
Stick it on a Wall
When I first started thinking about this blog, I thought the Altitude Map would be stuck as a big chart on the wall with the relevant information pinned in the right places. But since the Corona Virus Pandemic the world has changed, so a soft version with links to the documents and/or wiki pages could be an alternative of doing this going forward.
Cloud Level
We start with the Cloud Level.
Cloud Level is where we define or envision the Product, create a Product Vision, define the Product Strategy and any Outcomes. It is at a high, more abstract level and defines the product we are creating.
A product vision should have a purpose, that is, the problem is it trying to solve and secondly, what positive change is it trying to bring about. I’m not going to start talking about creating Product Visions, there is loads on the web about how to do so, but I particularly like Roman Pilcher’s Vision Board which is a great way of defining a vision, the strategy and what outcomes you want.
Again from Roman Pilcher, a Product Strategy should contain, as a minimum:
- the market for the product and the specific needs it will address.
- the product’s key differentiators or unique selling proposition.
- the company’s business goals for the product.
That last point also covers the Outcomes but it is definitely worth having these recorded separately too. Outcomes and Key Results (OKR’s) are useful here too.
That’s it at cloud level. Everything we do from this point should refer back to and be validated by the Product Vision, the Product Strategy and the Product Outcomes, so putting them in a prominent place at Cloud Level where the whole team can refer to them is a good idea.
Kite Level
The next level is the Kite Level.
It is Kite Level where we start to breakdown and record what we need to achieve the Vision, Strategy and Goals.
Here we capture and record the Personas of the users and customers who will use the product, the User Journeys they need to complete, an idea of the Functions required to achieve them and maybe some high level Epic Stories to define those Functions. Again I am not going to go into how you would create these but using tools such as a Narrative Canvas, Persona Templates and User Journey Maps are a great way of capturing and defining these.
Once we have our initial Personas, User Journeys and Functions we can then start to add a high level Roadmap and Release Plan. These will definitely change over time, a Roadmap is not a project plan, so dates, functionality and deliverables are not written in stone, never to be changed. But putting them on the Altitude Map gives them prominence and allows the team, stakeholder and others to follow progress as they get updated over time.
Sea Level
The next level is Sea Level
Sea Level is great. At Sea Level we have the Sprint Goals and User Stories. These are the needs and changes that the delivery team will implement next and could include development stories, experiments, spikes, tech debt stories and research stories. If we are running with Scrum, Sprint Goals sit at this level. Sprint Goals are what we are delivering and the user stories are a means to achieve that goal.
Everything above and including this level live in what I call the Product Domain. I don’t mean it is only used by the product team or product owner but everything from Sea Level up to Cloud Level defines the product in a non technical way and is used to convey information to stakeholders, users, customers, programme teams and for discussions with and by the delivery teams. Everything above sea level should drive and inform everything that happens below sea level which is what I am going to cover next.
Underwater
Underwater is the next level.
Underwater is where the action takes place. Here we have the output from the user stories, that is, the tasks required to complete the stories, any experiments, UI/UX, Architecture changes, Architecture designs, test scripts, prototypes which can be paper based or coded, whatever, any designs and things like the definition of done live down here.
One area that I’ve not put on the diagram that might sit here are constraints but equally they might sit above. I think business constraints such as business rules or legal requirements should sit above Sea Level and technical constraints and for that matter dependencies need to sit below Sea Level underwater. You decide.
I’ve also put User Research underwater. I would argue that user research is an output from experimentation and investigation, so should sit underwater, and a user researcher is part of the delivery team. However, if you disagree and want to put it above Sea Level that is again up to you.
Sea Bed
The final level is the Sea Bed.
This is where the code, automated tests, CI/CD pipelines and the code repository sit along with the Product Increments. The product increment is the output from the sprint/iteration or the release candidate.
Everything from Sea Level Down is the Technical Domain. I’ve drawn it with an overlap because the boundary between the Product Domain and the Technical Domain should not be a hard, fixed boundary but a fluid join where the Product Domain and Technical Domains merge.
The Whole Map
Remember that everything above sea level is used to define and qualify everything that is created below sea level. If what you are doing is not part of a sprint goal and does not equate to the Vision, Strategy and Outcomes defined, should you be doing it? Everything created below Sea Level should be validated against everything above Sea Level.
Equally, we should review and revise everything that is defined above sea level using the information we have discovered and the outputs we have created below sea level. There must be a feedback loop, leading to revision and an emergent product solution.
We also mustn’t think of it as absolutely split by the Product Domain and the Technical Domain, although they are useful splits, but as a Team Domain and all the Team need to be involved from Cloud Level to Sea Bed. Developers and Testers for instance need to know, understand and should help define the Vision of the product they are developing, likewise the Product Owner or Product Managers and stakeholders should have an understanding of the development and release processes. This way the whole product development is a collaborative process between the Product team and the Delivery team.
Visualise the Delivery
So in summary the Altitude Map is great way of providing a visual representation showing the flow of inputs, outputs and activities needed to define and develop a product from the Product Vision. Using the various levels helps you understand where something should sit and who should be doing it. Make it a living representation and keep it up to date, adjusted and amended as the delivery progresses and you learn more things.
Use it as a collaborative tool for the whole Product Team.
I hope you found that interesting and useful. Thank you for reading.
About the Author
Martin Boler is an experienced freelance Agile Delivery Manager, Scrum Master and Agile Coach. He has been practising and promoting agility in the work place for over 12 years for organisations such as NHS Digital, Travelodge, Kingfisher, Nokia, Virgin Atlantic Airways, British Gas and Flybe. He can provide training, coaching and delivery management on a freelance basis. If you want to know more please contact him here or visit www.xcitedevelopments.co.uk.
