Search the Community
Showing results for tags 'issue type'.
Found 15 results
-
AOR: Development Workflow: Standard Build Workflow --------------- The Build & Configure issue type is used for tasks that include system configurations and building of hardware. This is often used to setting up and configure systems, but can also be used for infrastructure activities such as configuring networks or setting up access. -
AOR: Generic Workflow: Standard Task Workflow --------------- The Sub-Task are used to break down base issues into smaller bits to make things easier to keep track of for the assignee or a base issue. Sub-tasks should never be deliverables or include any form of AOR handover. It should simply be steps to complete the base issue itself. -
AOR: Generic Workflow: Standard Task Workflow --------------- The Task issue type is used for generic activities that do not include any form of deliverable or need an AOR handover. This is usually mundane tasks such as prepare a meeting or buy cake for the team for the next retrospective. -
AOR: Generic Workflow: Standard Task Workflow --------------- The Epic is used differently in the Build workflow and in the Portfolio workflow. In both cases, however, it is used as a container for other things to be placed in. In the build workflow, an Epic is a Feature. That means that each Epic is a deliverable feature that when released is fully functional and provide value. In the Portfolio workflow, we use the Epic as a way to group projects into a Program. -
AOR: Generic Workflow: Standard Task Workflow --------------- The Investigation issue type is used for tasks that require some form of investigation. This includes helping out with requirements, making estimations or writing technical solutions on high and low levels. -
AOR: Design Workflow: Standard Design Workflow --------------- The design issue type is used for both UX and UI tasks. -
AOR: Development Workflow: Standard Build Workflow --------------- The Backend Development issue type is used as a work order for backend development. -
AOR: Development Workflow: Standard Build Workflow --------------- The Frontend Development issue type is used as a work order for frontend development. -
AOR: Development --------------- A Defect is a known error that has been allowed to be placed in production. For normal defect management we place a defect sub-task in the base issue type and for errors found in production we use the Incident issue type. -
AOR: Development --------------- The defect sub-task is used during fulfillment, where a base issue type does not fulfil the requirements acceptance criteria. This way we block the base issue type from completion until the defect sub-task has been fixed, or it has been broken out as a known defect that we allow to be present in production. -
AOR: Development --------------- The incident issue type is used only for things that are wrong in production. All incidents are verified against requirements to ensure the Incident is a valid error from what has been agreed upon. Things that are wrong, that has not been defined in a requirement, or is a part of an implicit requirement, can NOT be an incident. These should instead be logged as new requirements. Incidents are managed through the post go-live process and usually follow an ITSM based support setup. -
AOR: Management Workflow: Standard Build Workflow --------------- The story Issue Type is the basic issue type that is pre-configured in Jira Software. The purpose of the story is to act as a placeholder for some form of need, usually in the form of a user story. Because the Story is a generic issue type, it works for all types of work in an Agile methodology. Also, because the Story is generic, it is often misused and is used as generic need of various sizes. That makes the Story a versatile, but also confusing issue type to use. For this reason, we do not use the Story issue type in the Flexible Atlassian Setup. Instead, we use focused issue types such as frontend development, backend development, build and configure and Design instead. For generic research and development type of activities, we can still use the Investigation issue type. -
Your new issue type will be added to the default issue type scheme. You can configure this and any other issue type schemes to group your issue types and associate them with one or more projects.
-
I often get questions on how I think the best setup for Jira and Confluence should look when I meet organizations. Because of that I will make a series of posts about this where I setup Jira and Confluence from scratch. This will include not just how I do things, but also the thought behind it. I hope you will find this useful for setting up your own setup in Jira and Confluence. This series will be divided into several parts. This is because adding every step in a single post would make for a very long blog post. Dividing into a series also make it easier for you to look at specific parts that is most interesting for you at the moment. The parts that I have in mind could change as I write the series, but at the moment the plan is this: Part 1: Defining the tools Part 2: Defining Jira Issue Types Part 3: Defining Jira Issue workflows Part 4: Defining Jira Screens & Custom fields Part 5: Defining Jira security & access Part 6: Defining Confluence Information Structure Part 7: Defining Confluence Requirement Templates Part 8: Defining Confluence Design Templates With the setup completed in Jira and Confluence, I will probably add a second series called "Work processes in Confluence & Jira - From Need to Deploy" where we go through how to use the setup from a practical point of view. It will be a more generic process, so it can be used in any methodology with some minor tweaks. If anyone wants, I could also add a post about how to use the power of Jira and Confluence for programmers without ever leaving your IDE. Is there anything you miss from this series that you feel I should add?-
- 2
-
-
-
- jira
- issue type
- (and 3 more)
-
I often get questions on how I think the best setup for Jira and Confluence should look when I meet organizations. Because of that I will make a series of posts about this where I setup Jira and Confluence from scratch. This will include not just how I do things, but also the thought behind it. I hope you will find this useful for setting up your own setup in Jira and Confluence. This series will be divided into several parts. This is because adding every step in a single post would make for a very long blog post. Dividing into a series also make it easier for you to look at specific parts that is most interesting for you at the moment. The parts that I have in mind could change as I write the series, but at the moment the plan is this: Part 1: Defining the tools Part 2: Defining Jira Issue Types Part 3: Defining Jira Issue workflows Part 4: Defining Jira Screens & Custom fields Part 5: Defining Jira security & access Part 6: Defining Confluence Information Structure Part 7: Defining Confluence Requirement Templates Part 8: Defining Confluence Design Templates With the setup completed in Jira and Confluence, I will probably add a second series called "Work processes in Confluence & Jira - From Need to Deploy" where we go through how to use the setup from a practical point of view. It will be a more generic process, so it can be used in any methodology with some minor tweaks. If anyone wants, I could also add a post about how to use the power of Jira and Confluence for programmers without ever leaving your IDE. Is there anything you miss from this series that you feel I should add? View full blog article
