Allow an issue to be in multiple iterations

[knyghty]

Right now, if there's work left over from an iteration, we have to move it to the next one. We can't assign an issue to multiple iterations. As such, the burn up charts are misleading - it looks like every issue is getting done in every iteration, but usually there are some issues carried over.

It would be useful to be able to use the burn up chart as a way to measure how well we're doing, but it's not currently possible to use it that way.

[fiedl]

As of 2023-01-25, I haven't found this in github's roadmap.

Has anyone found a workaround for this usecase?

[beegan]

I've encountered a need for this while using projects to manage a feature development cycle. Some tasks we have estimated to take two weeks, but our iteration loop is 1 week in length. We want to be able to set that feature to run across multiple iterations so that our calendar view is realistic. What I'm having to do now is to put it in the earlier week, have the estimated work for that iteration be above the capacity available, and then under-assign capacity for week 2.

[abdonrd]

This would be really nice!

[MrChocolateMoose]

Agreed. This is a huge deficiency that makes it difficult to provide required insights to stakeholders. If Github wants to target the business market with Projects, this is mandatory in my opinion.

[dsantomaso]

Same here, I've just started using GitHub to manage a project, and it would be a nice feature to have.

[JPereira-FJB]

Similarly, I'd like to see (in a roadmap view) the start/end dates of 2 types of iterations (sprints - which are short duration, and development cycles - with a longer duration). I don't see that option, I think. Any idea how I could see both types of start/end date in a single view?

[iploooox]

Same would be good to be able to plan an issue for multiple iterations

[therickfactr]

In 20 years of practicing Scrum, any issue that is more than one Sprint become an Epic with sub-issues that are assigned to specific sprints.

[Alex-ley]

Any update GitHub?

[quick007]

This would be an amazing feature to have, sad that it's currently lacking :/

[DemianParkhomenko]

We really need this feature

[partydrone]

As I read through the comments here, I wondered if I would consider changing how I or my team works. For example, suppose a single issue is too large to fit within a single iteration. In that case, you might elevate that to a tracking issue, break it down into more minor issues that will fit in an iteration, and use those issues to track the work.

I'm not against having this feature. Looking at some of the reasons why made me think, though. 🙂

[quick007]

Another idea: what if tasks (when you put checkboxes in) in an issue could be spread across multiple iterations?

[therickfactr]

Click on the "Convert to sub-issue" or "Convert to issue" link to the right of the item (the one with the checkbox) in the description of the PR. Create multiple sub-issues - one for each iteration, or maybe more. Break the work down into manageable "bites".

[Alexander-Jordan]

This is something I miss a lot when using Project Boards for my work and personal life.
As others have pointed out, without this feature it makes not much sense to even view the graphs and their data as the truth.
I also use the Roadmap view, and when an issue passes from one iteration to another, this view doesn't work either as expected.

The main problem: from these views, it looks like all planning is on point when it actually isn't necessarily.

As of now, it's still not planned in the public roadmap. Hopefully it will be soon :)

[Alexander-Jordan]

As a workaround, I added an extra Iteration field and named it Started:

This means I have to add iterations to both iteration fields as time goes by, and I have to set both when starting an issue.
But with this it allows me to see when an issue was started and during which iteration it was completed.

[gpi-eaglys]

This iteration concept must have been inspired by Agile's sprint concept. Which, as we know, have been twisted and misused in ways that do not reflect much how actual work is structured. I suggest against re-creating JIRA here.

burn up charts are misleading

it makes not much sense to even view the graphs

Agree. Total nonsense.
I wonder what sort of hubris drives the assumption that all tickets take up exactly one single iteration in its full length to accomplish. Because the Roadmap (with its bars) reflects exactly this assumption.

There is a great misconception about the units of planned work and units of deliverables. Not every iteration of planned work produces a deliverable. I am reluctant to split up a single deliverable (e.g. refactoring a project ) into iteration level units (refactoring 100 files a week).

Otherwise GitHub projects is awesome.

[TikoyX]

I can't believe GitHub still haven't looked at this issue at all.
It is, yet another, point that for me indicates how bad GitHub actually is. The more i dive into its functions the more everything seems like a half-baked feature

[justintemps]

I love Github projects and think this is the one feature it's missing. It's not always possible to know how many iterations a single ticket is going to require to complete. This doesn't seem like an overly complicated feature to implement and clearly lots of people want it.

[rmdwirizki]

This feature is highly anticipated by my team. I am currently adding a field called Sprint Extensions to show how many times an issue has been carried over to subsequent sprints, as illustrated below:

It would be great if GitHub Projects provided a built-in solution for handling carried-over issues.

[Alexander-Jordan]

@rmdwirizki I did something similar to you, but instead of an option field I added an extra Iteration field and named it Started:

This means I have to add iterations to both iteration fields as time goes by, and I have to set both when starting an issue.
But with this it allows me to see when an issue was started and during which iteration it was completed.

[moonbrew]

I have been using a start date field and it seems to be a workaround. Have a look.

The Date fields filter needs to be setup this way: