Backlog 3D by Mateusz Srebrny
Keeping track of backlog of a single-team project tends to be pretty much straightforward. You break down the product into small bits of functionality, order them by the importance and put into a spreadsheet or even a wiki page.
The whole thing gets much less obvious when your project team gets bigger and the product more complex. Suddenly the flat list of user stories stops giving you enough insight into what is going on in the project. Even worse - you’re not able to build a flat list of anything out of a bunch of separate backlogs of your sub teams.
This is the situation I am currently dealing with. I am coaching a team of 40 developers and we need to plan and track half a year of product increment. I will share the approaches we took and the reasons why we are still looking for a better way :)
|Last Updated||16 Jul 19:07|