Zooming to the right level.
In order to see more and more of the details coming from the big picture, it is good to look at things at a far distance at first. Depending on how much detail is to become visible, we want to be able to reduce this distance.
This is the basic idea of flight levels. In order to find again what belongs together, the higher flight levels form a bracket around the details below.
3 to 4 levels are enough.
Even relatively complex projects / organisational units can be structured sufficiently well via 3 maximum 4 levels.
Projects with up to 4 teams of 10 people: Epics, stories, tasks, whereby an epic summarises everything that cannot be developed in a sprint. This size can be coordinated by a product owner team.
Projects with significantly more than 4 teams: Epics in this case represent everything that takes longer than one stage to develop. Between Epic and Story there are the Features. Features represent the portion for exactly one stage and often need contributions from several teams.
Levels structure the communication.
Flight levels not only structure work packages, but also determine communication in large teams and projects.
The top level provides orientation, while the bottom level can focus on direct work on the implementation of the product.
Autonomous action at each level is essential to maintain simplicity. The appropriate pace and depth of exchange between the levels is a key determinant of agility. Agile coaches are called upon to design the right routines and ceremonies.
Why do we call it a story?
The term story has become established in the agile world. The story format allows very precise formulations of desired outcomes. They were formulated from the customer’s point of view. Format: “I as … would like … to …”.
It has been shown that even outside the software world, in mechatronics and others, the precision in describing the results of a sprint benefits greatly when they are written in story format.
You can see who needs the result and what it is needed for. If it remains unclear who needs the result and/or what we are working on it for, that is a good reason not to work on it at all.