Planning boards – sometimes called task boards – are a great way to make work visible, facility teamwork, and surface impediments. The work required for a given iteration of software is broken down into a collection of individually owned tasks and then, as work progresses, we watch those tasks migrate towards the right hand side with a sense of satisfaction.
This is unprecedented transparency and one of the reasons why I love it, but it does have one small shortcoming. If you’re not intimately familiar with the work (say, for example, a non-technical stakeholder) then it can be a bit hard to determine meaning. Yes things are moving along, but what really are those things? Of the 4 stories we’re doing this sprint, which business feature does this progress (or impediment) relate to? It looks almost all done but are we saying that we’ve done 3 of our features and we’re working on the 4th or that we have we done 80% of each of them?
We do want the business to be engaged and to participate in the process so we ought to try and make it interpretable for them.
Some of my guys recently started adding a 2nd dimension to their planning boards; features. By adding a horizontal view which groups tasks by the requirement they relate to as well as the usual vertical view which groups tasks by their status (not started, done, etc) you get an at-a-glance view of the progress of each piece of business-relevant functionality, rather than just a broad sense of things happening.
Even I find this easier to consume! Rock on you little geniuses (you know who you are).
No comments:
Post a Comment