This is really hard to summarize here and I do not know the best way to implement it in VersionOne either – My main goal here is to express what I am thinking to see if it could trigger any changes in this area of the product.
We are working our way through an enterprise deployment of scrum in our company. One place we really need more abilities in VersionOne is in release planning and tracking.
Since the majority of our org is still waterfall, we have not transitioned to an agile approach to release planning in our scrum teams, but we are currently running a pilot exercise with one team’s. In general we run date-based projects (waterfall prevents that from begin a reality to a good extent, but the intent and expectations are that we do date-driven releases).
What we realized is that as we proceed with our adoption, our Uber POs, key delegates from the various teams, and stakeholders need the ability to see releases in both planning and tracking views that allow them to work at an epic and/or feature group level of abstraction, with the option of drilling down to the story level, if more details are needed. Some of this may be manageable in reports today, but we'd rather see this work much more like how sprint planning and tracking is done, complete with a storyboard-like view (It would be an epic or feature group board instead).
We are trying to set up a model where this team of Uber PO's, stakeholders and key team delegates meet periodically in a meta-scrum type of meeting and review the release in progress and make prioritization adjustments and tradeoffs, at a high level, as the realities of teams’ sprints evolve and as new more important items get identified along the way. They also need to see the impacts that has on future release plans already defined (I do not mean fix-feature plans, I mean vision-based, feature-estimated plans)
With our pilot team we have to do this exercise using sticky-notes, where we show epics grouped into 2-3 releases based on ballpark estimates of velocity. As the first release starts to be worked by the team, a new item comes up that “must” be done in the release 1 timeframe, which means something has to give, priorities need to be shuffled, etc. By that same token, if an epic in release 1 suddenly blossomed into more work than anticipated, then tradeoffs, priorities etc need to be reevaluated. As you could see, if we add more teams into this, the need to see this higher level “epic/feature group board” that shows status for a single release (what is in progress, what is accepted, etc.), and we would need a way to see how release 2 and 3 will be impacted based on the realities of release 1.
by: Tom W. | over a year ago | Product Planning
Comments
Roadmapping hits at the core of this idea. The initial release for Roadmapping came in Summer '10. We're always happy to get more specific feedback about where to go from there with it, so feel free to create other ideas to guide us.
Support for agile portfolio management was introduced in the Winter 2012 release. Many different features help to support this including Epicboards, epic dashboards, enhanced drag & drop ranking within epic trees and first-class epic assets (meaning more flexibility with custom fields, project workspaces, exporting, etc).
Further details about the Winter 2012 release can be found in the release notes:
http://community.versionone.com/Release%20Notes/ReleaseNotes2012Winter.aspx