User Stories, and Flight Levels

A while back, I had a chat at work with our Scrum Master Susmita Banik , and we came up with an interesting metaphor for the focus of work for PMs, POs, and engineering teams at Quandoo. The credit really goes to Susmita, I just like the metaphor so much that I can’t hold back. Please let us know what you think.

It started with us discussing quarterly product roadmap planning, and observing that PMs and POs are currently less than 1-2 months ahead of the engineering teams in terms of planning and backlog building. The desirable state is that while the engineering team is working on the top entries in the backlog, the POs are already preparing things to be there in one month, and the PMs are working on things even farther out. That allows for steady throughput.

One thing that apparently happens a lot is that discussions about user story slicing get lost in technical and implementation detail. That’s not what user stories should describe though; decisions about implementation details are in the hands of the engineering team. Occasional consulting with the PO notwithstanding.

It is indeed a frequent antipattern in meetings: they wildly flip between different “flight levels” or “altitudes” and go off track, frustrating participants and yielding no outcome. (This is surely part of people’s general frustration with meetings. I keep saying it’s not meetings that are the problem, but bad meetings.)

This is what the metaphor Susmita and I developed is all about: mapping types of work - and types of work typically done by certain roles - to something akin to flight levels. Here goes.

Think your favourite maps product. And think of charting and going on a journey.

The task of planning, usually driven and significantly carried out by PMs and POs, with some consultation from engineers, is the really high level view on the map. No physical details are visible (satellite image view is off). At this level, the point is to state “we’re going from A to B, and the route is roughly this, with maybe these milestones”.

One flight level down, the journey is charted, taking landmarks into account for orientation. Satellite image view is now on, and the zoom level is higher. This is typically done by POs, with more consultation from engineers. The focus is on going from one milestone to the next, and implementation details are still not the main topic, but may serve as orientation from time to time.

When the path is walked, and stories get implemented, the map is switched to street view. Details have full attention now, and rightfully so. Which corner to turn, which street to cross and where … these questions are now relevant.

What’s important is that zooming out to one or two levels higher is possible at all levels, as a reminder of what the big picture is like, and what purpose all of the nitty-gritty details ultimately serve. What’s also important is that everyone has a meaningful contribution that relies on their particular expertise. It’s never just a technical question, or just a high-level planning question, or just a story slicing granularity question. It’s the collaboration across these levels, in an appropriate and solution oriented way, that eventually brings everyone to the target.

As an example, take going from somewhere in Berlin-Friedrichshain to the Quandoo office by public transportation. That’s the high level view in planning. The stories are charted by breaking the route down into segments of the trip (likely ending with taking U2 from Alexanderplatz if it's not broken again, or M10 from Warschauer Stra?e). Implementation of each of the stories involves all kinds of detail decisions, like which entrance to take in an U-Bahn station, or where to cross a street. Even though different people may have contributed to these things at the different levels, in the end, the entire party gets to the office, thanks to the collaboration.

How does this work?

(Thank you once more for the discussion, Susmita!)

(This was first published in my public blog.)