In a classic Jira project there are building blocks which is required to be created and assembled to onboard a project .Those building blocks like, project, issue types, workflow, screens, permissions and notifications are independent entities. They do not converse with each other. E.g., Team A has created a Jira project as "Legos" and two issue types are decided "Story and bug" to be tracked. The team has also gone ahead and created two workflows for Story and bug. Now as these building blocks are created, they are independent, The issue types chosen will not reflect under the project or the issue types will not traverse as per the workflow, because they are not linked to one another "Schemes" are used to assemble these building blocks. Each of the blocks here will have the separate schemes created and integrated. This blog shares details on the concept, creation and linking of each schemes to the project Issue type schemes Issue types are the list of
Jira project on-boarding, in a classic project of Jira there are key building blocks which needs to be modeled and assembled, to ensure successful on- boarding. Not only for the Jira admin's,it is also important for the end user and requirement givers, to understand the building blocks and their interaction. This add-on will bring in a different perspective on what to expect from Jira. Pictorial representation of how the building blocks are layered is shared below 1. Projects A project in Jira is the level at which you want to track your delivery / execution. A Jira project need not necessarily be the same as your software Project. Example: You have a project signed for Customer A and you have formed 5 teams: Software, Hardware , Ux, Information development & security team. So now, you can have your Jira project tracked at the customer level or at the team level You can also have a totally independent item, which is not part of your project life cycle, like Organization custo