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?

205 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Magnus Bjork shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    25 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Oscar Vasquez commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Shay commented  ·   ·  Flag as inappropriate

        I also need this capability to properly communicate the plan to the business

      • Andy Fritsch commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Epics and Features need to be able to span multiple sprints. I prefer to use a sprint hierarchy to help reflect different timelines.

        For example:
        2018\Q1\Sprint1
        2018\Q1\Sprint2

        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.

      • Marcus Fields commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      • Jan Krogh commented  ·   ·  Flag as inappropriate

        Features spanning multiple sprints would really step this tool up to improve communication between development teams and business

      • David Green commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

        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.

      ← Previous 1

      Feedback and Knowledge Base