Walter Buggenhout Community Champion

Hi @[deleted], It seems as if your release dates in Portfolio are being considered as dynamic instead of fixed dates. You can check and update the setting from the releases tab in Portfolio. Select your release and click edit. Make sure to set the relase dates to fixed start date and / or fixed release date. And after…

Hi @[deleted], What do you mean with 'they got restarted and all changes are lost'?

Hi @timmurko I'm unsure as to what you want to achieve, but it sounds like reporting. Have you considered pulling the data from your plan(s) into a reporting tool like EazyBI (based on the filters you use as input to your plan) and aggregating your worklogs there?

Hi @timmurko , Thanks for reaching out. But I am afraid that what you are trying to achieve is not really possible. A Portfolio plan retrieves its data through different dynamic data sources: an agile board, a saved filter or a Jira project. The issues belonging to a plan can be retrieved through those sources, but the ID…

Hi Marc, That does not really matter. To get you started, a Kanban project might be a good one to get you started, as the kanban board that comes with it is a good representation of your ongoing initiatives. Once you have created the project, I would advise you to at least do the following configuration changes: * Make…

I second @David Waldhans and @Tanya L Christensen too on this. To be precise, components are somewhat off topic as well, since they aren't issue types. The following graphic pretty much illustrates the hierarchy from project down to the subtask level. It also includes components and versions, which you can use to organise…

Definitely, @Matías Génova. That is absolutely common practice. Boards allow you to map statuses from different workflows. So it is technically entirely possible to deal with different workflows in a single board. However, in software teams, boards are commonly used to track the development backlog. As Wendy's question…

Hi @wendy.yurcic, This is a common challenge and pretty easy to resolve. The common tasks you mention are a different type of work, as you correctly observe. They usually follow another, much simpler process or workflow than - let's say - stories or bugs. So it is perfectly fine to create one/more specific issue types for…

Hi @Aishwarya, This is a really difficult one to diagnose remotely, but what tends to happen sometimes is issues being excluded because they are assigned to a release that is not included in your plan. Also, if the fix version field is hidden in a Jira project, issues from that project will not be imported (known…

You should create a Program, which is a special type of plan designed specifically for this purpose. If you want to learn more, check out Atlassian documentation.

Hi @Fatima, This looks as if you pulled in a Jira macro and accidentally selected multiple issues through a JQL filter. Edit your Confluence page and edit the Jira macro in your table. Suppose you just want to view the PRODUCT-11 epic, just type 'PRODUCT-11' in the search box and press enter to make sure you just see the…

Hi @Ahmed Dewjee, @Jack Brickey is right about the scriptrunner app for this. You can use a JQL statement like this: issueFunction in Issuetype = Story and issuesInEpics("Projects in (ProjectA, ProjectB) and status = 'in progress'") where ProjectA and ProjectB are the projects that hold your epics. The issuetype = Story…

Those are the best ones :-)

Hi @Pratima Peyyety, @Vasiliy Zverev and @PADMA KOTHAKOTA are correct about the workflow. If there is no transition defined to a previous status, you cannot go back. Often - following good practices - workflows are designed like this on purpose as you essentially want to move work forward. If a mistake is made…

Hi @james_warr, As the control chart is based on the board columns, you indeed need the column on your board. You have 2 ways to keep your Done column clean: one is to periodically 'release' the issues in the right column of you board. There should be a link called 'Release ...' in the top right corner of your board.…

Good starting point indeed. Also have a look at the related content / questions to this question.

Maybe not entirely an exact answer to your question, but if user friendliness is what you are after, you could also move the Product Management fields on a separate tab. That might be interesting for both your developers as your product managers.

Okay @Ken Uehling, Trust me on this one: moving issues does not cause any downtime at all. Moving 400 issues will take no more than a couple of minutes while your Jira instance keeps running just fine. But we are back at the beginning of this thread, where it is clear that you currently don't see the difference between a…

Hey @Ken Uehling, If you are going to move the issues, you will just be moving them into the existing project and as such into the already existing board. There will be no need for a new board. If there is one thing that you shouldn't do in any way, it is copying issues. It will create a duplicate of the same task, so you…

Hey @Ken Uehling, In that case, don't do anything now. Just do the move when the organisation is ready for it.

Hi @Ken Uehling, Yes. Just be aware that you will be moving the issues, not copying them.

Hi @Ken Uehling, For whatever reason, someone initially decided to manage the issues in separate projects in Jira. That means this 'someone' must have thought they did not belong together. If you want to bring them together on a single board, this is usually because one and the same team is working on both projects and -…

Hi @Arron Tran, You say you introduced (Jira) kanban to your legal team. As you probably know, kanban is a methodology that focuses on improving the flow of work. I am sure you are using a kanban board for the legal team. Just the board itself can show you where you have bottlenecks in your systems: the columns in your…

Hi @mathew best, In your board configuration, check which field is configured as the estimation statistic: Make sure that it is the same field you use for the story point estimation. For more background, also have a look at the documentation about estimation and time tracking, which are different things.

@Alexey Matveev is suggesting that you keep both projects and configure your existing kanban board to display issues from both projects. In order to do so, you would go into your board configuration, locate the current board filter and then edit this to something like: Project in (ProjectA, ProjectB) All your issues will…

Hi @Madhu Reddy, 'Created by anyone' is unfortunately not the best chosen wording in the history of Atlassian products. It actually means "created by anyone whose tickets you are allowed to see". And to be very specific: those are the following tickets: * tickets you created yourself * tickets that have been explicitly…

Hi @Marcos Sciarra, There is an open feature request for this: JSDSERVER-222. You might want to vote for it and keep watching the issue in order to stay updated. I agree that this is a really valuable feature, which was already released in Jira Cloud quite a while ago. In the meantime, you could consider building similar…

Hi @Mathias Koprek, No, that is not something you can do with a flag. It also depends what you are trying to achieve here. If your aim is to make it clear to your customer that you have found a solution, you could use some outspoken styling in your response to make it clear that this is your solution. To give you an…

Hi @llagos, 'raise a request' is the way customers raise tickets: through the customer portal. The 'create' button is meant to create issues as an internal user. This is not just a matter of convenience. The way you create a ticket determines is also linked to a channel and a request type. With the raise a request type…

Hi @Marc Taylor, A good place to start would be the Control Chart. The report is associated with agile boards and is a really powerful instrument to drill into this type of information.