Overview
After several attempts, it seems that the best way to represent dependencies and progress for something to do is the good old Gantt view.
Not that other representations doesn't work but Gantt as the advantage of being so well known that it's both re-assuring for the reader and doesn't require a dedicated training or documentation. In this case we cannot assume that readers (various forms of managers) of this information will have a good understanding of common agile progress indicators (burnup, burndown, cumulative flow charts, etc) but most of the time they will be able to read a Gantt.
That said, this feature is meant to be delivered on top of something (Program Management) that might lack of two things:
- % of completion
- dates (start, expected end, actual end)
Progress
The % of completion is not a complex thing to have. In regular Gantt, it's a percentage on a task (a integer value between 0 and 100 for instance). In an agile world, it's either a remaining effort (there are 5 points remaining on 8 initially planned it means that 37.5% of the story is done) or it can even be computed with the amount of cards done (there are 10 out of 20 cards Done, it means that 50% of the story is done).
Dates
For dates it's less obvious.
In Agile developments, we usually don't keep track of those information and it's even often identify as an anti-pattern when teams do so. However in real world, we know that both kind of teams exists: the team that keep track of dates and the teams that don't.
Program management is meant to aggregate different teams working on a common set of features but with separated practices. Those different practices implies that they work on different work spaces (projects) otherwise, it would be easier to have all the teams sharing the same backlog in one central work space.
The good news is that we can support both kind of teams with one simple idea:
- for "dates" teams we already have the information.
- for "no dates" teams we can actually compute that automatically !
When a Story is planned in a given iteration that means that it will start sometimes after the start of the iteration and it should end before the end of the iteration. That's the trick ! When dates are not there on Stories, we can infer them from the milestones they are planned in (Iterations, Program Increment, etc).
On the mock-up bellow (very early draft) you can see a Roadmap with the 2 kind of dates:
- In "plain" the teams that manage actual dates
- In "dotted line" the teams for which those dates where automatically computed.
