If you ask the people at the top the detail of what is going into the "Platinum Release" sheduled for next year they won't really know, but they do know that they really really need it to stay ahead of the competition / win that new business etc.
Here this is where you can use some agile terms to get a level of insight and begin the agile breakdown. I normally propose to organisations that they consider each of these top level milestones on the roadmap and assign "themes" to them which bullet out the contents. At board level there will be some comprehension that within a certain new product it will have different things in it, and even at this level this is all useful information despite the very broad nature of the content.
If you considered a fictitious Microsoft Office 20XX product to be the next "Product release" then you could think that the "Themes" within could be "Word" "Excel" "Powerpoint" "Outlook" "Frontpage" "Publisher" and "Access". At board level this is a good enough level of detail; no one is being asked to specify "cross product cut and paste" as a requirement, however even here there are levels of prioritisation that could be deployed as needed; I would suggest Word and Excel are probably more strategically important than Frontpage for example.
These "Themes" can be taken on by groups of product owners to start creating "Epic stories" around each theme and in turn, with the help of business analysts and other parties, these epics can be broken down further into "User Stories".
The hierarchy of understanding therefore is as follows:
- User Stories
As Agile is effectively transparent, when it comes to having to broker the requirements (assuming they don't all fit (as they never do)) then there is a platform whereby, at top level whole branches of the development effort can be measured and considered, as well as the individual components on every branch. This means that someone could say "we are loosing Frontpage to secure the release" just as easily as "we are loosing cross product cut and paste as we cant afford the complexity".
Themes are not the solution to every project, however do provide a handy "Epic-epic" that is understandable at board level, without the directors having to get involved with "all that agile story mumbo jumbo".
Post a Comment