How can we improve Azure DevOps?

Delivery Plans - Features over sprint boundaries

This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/365685/delivery-plans-features-over-sprint-boundaries.html Delivery Plans Extension has the potential to show the planning for future features we implement to our stakeholders. We work in sprints of 3 weeks. Often, the development of a feature takes more than one sprint. It does not seem possible to let an epic or feature run over two sprints. Is that something you have considered? Or is there any smart work around?

Maybe allowing multiple iterations for a Feature or Epic is difficult because of the internals of the work items, but allowing to show the "parent" of a selected iteration (like the program increment) in a plan would be enough to cover this.

The planning tool would be a much less clumsy portfolio level communication tool if Epics or Features could span iterations. Many teams use PI's (Product/Project Increments) and the ability to align with those boundaries would make it useful. (to me)

I've been using the extension Stefan Riesen mentions below for sometime now and it is nearly there but not quite.
It's missing:
1. Placement based on time when the user stories become first active and closed.
2. Cross teams/project support.
3. Milestone marker.

VSTS team really needs to sort this out and have one system that works really well!

We moved from Rally to VSTS where there was road mapping support that just worked without all the extra headaches of VSTS. Jira and VersonOne also have road mapping.

Connecting some dots for Microsoft to help with the solution. In the Microsoft article for using VSTS to implement a Scaled Agile Framework (SAFe) https://bit.ly/2sUvBbS, it offers an iteration configuration example of nesting a set of short 2-week iterations within a longer-term (8 week) Product Increment iteration (PI) (or some other period like quarterly periods over the year). This PI iteration is an ideal context for visualizing longer spanning Epics and Features in Delivery Plans. However, Delivery Plans doesn't currently support visualizing at this higher level.

One way to solve this visualization problem would be to enable Delivery Plans to display any iteration level in the iteration hierarchy. As of this comment, Delivery Plans ignores all iterations in the hierarchy except the innermost iterations which it will display. If Delivery Plans could display work items at any iteration level, then users could assign Epics and Features to the parent iterations (Product Increments) that wrap the series of short sprints that feature teams use. This would allow users to configure a delivery plan that shows Epics and Features at the parent/wrapper/longer-term level thus enabling higher-level product and portfolio planning in Delivery Plans. And I don't think this would change the Work Item data model at all.

Also would like the ability to filter items using custom fields. Not every Feature we have should be visible to the rest of the business, e.g. we group up a bunch of user stories into Refactoring/Accessibility/etc. So having a custom field and being able to filter on the custom field would allow us to selectively hide items from the plan.

I think, if we could show the following two pieces of information with each feature, that will resolve some of the gaps:
(1) how many stories from this feature is part of this iteration (because going to the story level makes the list too long)
(2) is the feature getting completed with this iteration i.e. all stories in the feature are planned to be closed by the end of this iteration.

I too need this capability for the delivery plan to add ultimate value to the team. For me, it should drive off of the user stories assignment to an iteration. A feature might have 5 stories, three of which are assigned to iteration A. That should make the item show up on the Delivery Plan in that iteration. Then, if I assign the remaining 2 stories to iteration B, the feature should show as spanned across the iterations on the Delivery Plan.