Delivery Plans - Features over sprint boundaries
This suggestion is migrated to Developer Community. Please use below link to view the current status.
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?
We need the ability for a Feature to span multiple Sprints in order to accurately create a product plan. This limitation is the driving factor for my company pushing to switch to Jira.
The extension "Feature timeline and Epic Roadmap" will do this for one project, but my organization needs to see all active projects in one plan with Features spanning multiple sprints.
Is there a plan to have the new "feature timeline" extension incorporated into the Plans? We have many teams and we set up projects that can show all the teams in one portfolio, We want to have the "Feature timeline" functionality at the delivery plan level.
In the tutorial page for Delivery Plans, there's a picture that shows a feature across sprint boundaries (https://docs.microsoft.com/en-us/azure/devops/boards/plans/review-team-plans?view=vsts&tabs=new-nav).
However, there're no instructions on how to do this. Did anyone figure this out?
Oscar Vasquez commented
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)
Tim (aka Roberto) commented
I've been using the extension Stefan Riesen mentions below for sometime now and it is nearly there but not quite.
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.
Stefan Riesen commented
Just found, there is an extension that does exactly what is required: https://marketplace.visualstudio.com/items?itemName=ms-devlabs.workitem-feature-timeline-extension This makes the delivery plans obsoltete from my point of view
I also need this capability to properly communicate the plan to the business
Andy Fritsch commented
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.
Has anyone got an update on this? Delivery Plans were one of our primary reasons for wanting to move to VSTS and yet we can't show over what time line we expect to deliver our features.
Epics and Features need to be able to span multiple sprints. I prefer to use a sprint hierarchy to help reflect different timelines.
Epics\Features\WorkItems (user story, bugs, etc.)
They may not always align this way, but It's possible that Epics and Features can span multiple sprints and it would be really helpful to be able to see that.
Carlos Aganzo commented
This feature is fundamental for Plans to be useful.
Marcus Fields commented
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.
Davis John commented
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.
Andre Jacobs commented
We need this to do proper roadmap communication to business. Please add.
Andrei Marfievici commented
We want this!!!
Jan Krogh commented
Features spanning multiple sprints would really step this tool up to improve communication between development teams and business
David Green commented
Ability to see features/epics spanning iterations is critical for this to replace existing executive status reporting being done via SharePoint/Excel.
Chris H commented
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.