Uploaded image for project: 'Advanced Roadmaps'
  1. Advanced Roadmaps
  2. JPOSERVER-1900

Scheduling wrongly plan work for the first release even if released or in the past

This issue belongs to an archived project. You can view it, but you can't modify it. Learn more

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Medium Medium
    • None
    • None
    • Scheduling
    • None

      For Kanban team, the first available piece of work is assigned to the first list release even if it's far in the past. The next piece of work is then assigned to the next release matching today's date as expected.

      Releases in Portfolio only `disappear` when archived, so this even happens on versions marked as `Released`.

       

      To reproduce:

      • Create a kanban team
      • Create an issue with an estimate and no release assignment
      • Add a release started/released way back in the past (optionally mark it as released in JIRA)
      • Calculate

      The issue will be assigned to the past release wrongly. Switching the team to scrum shows the correct behavior.

        1. Program Status Breakdown.png
          Program Status Breakdown.png
          20 kB

            [JPOSERVER-1900] Scheduling wrongly plan work for the first release even if released or in the past

            Cameron Eldridge added a comment - - edited

            We want to be able to archive releases so that current issues are not erroneously assigned to past releases. However, archiving releases excludes them from the plan, along with all of the issues in those releases.

            As a result, the Status breakdown in the Scope view of a Program illustrates an inaccurate percentage of completion even if you filter the Completion Date to a much earlier date in time, e.g. 2010-01-01.

            EXAMPLE

            Actual number of issues in this sample Epic that ARE included in the plan's issue sources: 19

            After archiving a previous release, number of issues illustrated in the Status breakdown: 14

            This is a huge problem for Programs! If we don't archive releases, we have a cluttered plan that requires a lot of release ranking maintenance. If we do archive releases or manually exclude them from our plan, our reports are inaccurate.

             

            Please let me know if a ticket already exists to track this topic.

            Cameron Eldridge added a comment - - edited We want to be able to archive releases so that current issues are not erroneously assigned to past releases. However, archiving releases excludes them from the plan, along with all of the issues in those releases. As a result, the  Status breakdown  in the  Scope  view of a Program illustrates an inaccurate percentage of completion even if you filter the  Completion Date  to a much earlier date in time, e.g.  2010-01-01 . EXAMPLE Actual number of issues in this sample Epic that  ARE  included in the plan's issue sources:  19 After archiving a previous release, number of issues illustrated in the Status breakdown:  14 This is a huge problem for  Programs ! If we don't archive releases, we have a cluttered plan that requires a lot of release ranking maintenance. If we do archive releases or manually exclude them from our plan, our reports are inaccurate.   Please let me know if a ticket already exists to track this topic.

              Unassigned Unassigned
              tbarthelemy Thomas
              Archiver:
              atibrewal@atlassian.com Aakrity Tibrewal

                Created:
                Updated:
                Resolved:
                Archived: