Atlassian Team members are employees working across the company in a wide variety of roles.
September 9, 2024 edited
Hi @Ірина Семеновська ! Thanks so much for your feedback. Can you please clarify your request for me so I can better understand your use case? Were you wanting a way to persist the filters? How would the saving of filters allow you to avoid adding a label to each child issue?
Atlassian Team members are employees working across the company in a wide variety of roles.
September 9, 2024 edited
Hi @Andrei Eleodor Sirbu Thank you for providing your feedback, we appreciate it:) Unfortunately individual iteration durations cannot be modified after the program board has been created. However, we have a feature where you can sync each iteration to a sprint which might be able to help you out. You can set any start + end dates to your sprints within Jira which will allow you to use your sprint durations for each iteration. You can read more about it here. Please let me know if you have any further feedback or questions and I can help you out.
Some of my dev teams have started to use this new feature and really like it. We still see it flagged as 'beta', any ETA on when it will be officially released?
A quick update on this feature - it's a shame we are forced to have six iterations for a program board. We are forced to create a fake sprint in each team scrum board in order to be able to use the program board.
We try to use it with two program boards (one for features and one for user stories).
Do you think we will be able to chose the number of iterations ourselves ?
@William _Bill_ Klein we're currently aiming to have GA release delivered by the end of this Calendar year. The main feature we're building for this milestone will be a powerful visualisation of dependencies within the Program Board. I expect the Atlassian public roadmap should be updated sometime soon and will include this timeframe for the GA release.
Is there a plan to incorporate Fix Version aka Releases into the Program Board? My team is using Fix Version as our quasi-sprint grouping and would like the columns within the Program Board to represent the monthly releases rather than sprints.
There are already multiple apps providing Program Board functionalities on the Marketplace. Atlassian providing the exact same functionalities is impacting us and other vendors heavily.
We've invested years in our products and took major risks.
It is not just about us. Other vendors are also being impacted when Atlassian copies their functionality and puts the app out of business. See RFC-68 Action Items in Jira for other cases.
This is not a correct way of working: being an Marketplace owner to encourage vendors building apps, and then putting apps that work out of business by copying the functionalities.
Atlassian is now doing nothing different with Jira Plans than Microsoft did with Internet Explorer or Google Inc did with Google Search on Android / Chrome.
I have a question about scheduling on the program board. My goal is to use the board in our Scrum of Scrum to reflect the epics each of my team is working on at the program level, focusing on visualising WIP without displaying stories.
For example, some of my epics span 2 to 3 sprints, and I have stories allocated across both current and future sprints (no specific Due Data assigned). However, I'm seeing that these epics appear as unscheduled on program board.
Additionally, if an epic isn't completed in the current sprint, and there are stories allocated to upcoming sprint, will the epic automatically move to the next sprint's column on the board once the current sprint closes?
Hey all. Since program boards pull in 'To do' and 'In Progress' items, this would include items in an active current sprint, a planned future sprint and backlog items from our projects. Is this a common practice for everyone or do you have you backlog items as a different status? I struggle on how to differentiate between things in 'To Do' status within a planned/active sprint vs. what is in the backlog. Sure, I could write additional filters, etc. to exclude/include current and future sprints but this gets messy along the way. (This is what I do right now)
Anyones thoughts and practices would be appreciated.
Does the Program Board affect your Plan start and due dates? Or is the program board independent of the roadmap plan? I am trying to understand if I try to use the Program Board will this disrupt my plan?
Also if I plan on my program board will this make sprints in my team backlog? I am trying not do that anti pattern and it is too busy.
@Hari Shankar we had this issue in the plan. To correct this jira cloud uses UTC time which is 6 hours ahead of our CST time zone. I have all of my scrum masters ending the sprints at 5:30PM and this finally aligned the sprint end dates in the plan.
1. Due dates sprints use now do not overlap
2. Capacity view now is correct since there are not overlapping dates
Big Whoooo Hoo. This was killing us prior to figuring this out.
57 comments