Scott RollinsSr. Agile Consultant| AccenturePleasanton, Ca, United States
I''m often asked about best practices as it pertains to building or releasing a product roadmap? I''m curious to see how other Agile leaders field this particular question?
My first response is, why are you releasing a roadmap to begin with? A roadmap is really just a plan to release certain features at certain time frames. The whole value of being agile is adapting to the marketplace when it''s necessary to do so. The whole reason I never planned in the military is it''s just a waste of time. Never plan. Be prepared. Train. But, never plan. Every plan I''ve ever seen or heard went right out the door the second the first shot was fired. Plan to adapt. Plan to be available to the most valuable idea available the second its available. That''s a lot of available(s). But, makes the case of how important flexibility really is. Not just on the battlefield, but in business as well. Once it''s put on the roadmap, it''s like God put it there or something. And, no one has the courage to take it off.
I suggest not releasing any kind of roadmap. Just tell everyone, you are in for a surprise. It will also give you a excellent understanding of the value you are really providing for your stakeholders. Remember, 80% o the software we make never gets used. And, 98% o all software sold is considered crap and a failure. Stick to the one or two things your currently working on and call that good to go for a roadmap. Anything else is just marketing and not agile, in my opinion. Let marketing figure out some other way to earn their money.
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
I'm with Alistair: just provide a list of the features or user stories, by priority and packaged into sprints. Your unestimated features can still be listed but will be waiting for sprint assignment. That's not unusual for a roadmap. Saving Changes...
I've seen a good use of quarterly targets planned out through the next calendar year as a road map. This was for a software product company that needed to define what new features would be released and when. And, this is hugely important, the quarterly targets was established by the product owner, not by the agile team.
The establishment of these targets helped everybody: sales knew what they could sell when, the dev team ingested and shared this future vision, marketing could market, etc.
As for more ad hoc planning, I think the regular sprint ceremony of backlog pruning, prioritization and refinement provides the ability to course correct with every sprint. Saving Changes...
