New product or project development:
In an organization, this permission will not be granted to many people.
You can give it a key. The key will be prefix of issues number for issues created in the project.
You can give it a unique icon, call Avatar.
A JIRA project is sometime mapped to "Product" within software organizations. A new product may be a "project", but when you have multiple releases and start maintenance cycles, you are developing and maintaining a product which is typically created as a JIRA project.
This is a very good way to run an "integration" project, when a project involves the teams that are from multiple product and from multiple organizations.
You can create multiple boards. Multiple boards can exist simultaneously. A board is actually just a view of the issues in different columns.
It controls which issues types are used and what the possible transitions among issue types.
It is optional.
It is useful to have a default assignee for each component.
I found these columns useful for a board created for development:
Note that the status to column mapping is an implicit filter on a board.
The issue statuses that are not mapped will not be shown anywhere on the board.
For example, QA can create their own board to view only the statuses mapped to Ready for Test, Test in Progress, and Done.
The Filter Query determines which issues will be collected into a board.
Typically, the Board filter is based on a project and a set of issue types.
However, I found a good practice is to include the issues assigned to resources that are part of the project team.
project = projectA OR assignee in (member1, member2, member3)
Epic Link, component, label are also good filter criteria.
Each Swimlane can have its own filter criteria.
This can be used in the standup call.
When you call different people to get the status from them. Filter the board to show only the tickets that are owned by them.
1. Create a new JIRA project
You need to have the project administration permission to do so.In an organization, this permission will not be granted to many people.
You can give it a key. The key will be prefix of issues number for issues created in the project.
You can give it a unique icon, call Avatar.
A JIRA project is sometime mapped to "Product" within software organizations. A new product may be a "project", but when you have multiple releases and start maintenance cycles, you are developing and maintaining a product which is typically created as a JIRA project.
2. Create a Board
For a new development project, a new broad can be created for an existing JIRA project, or for a JQL, which is a query for collecting issues from multiple projects.This is a very good way to run an "integration" project, when a project involves the teams that are from multiple product and from multiple organizations.
You can create multiple boards. Multiple boards can exist simultaneously. A board is actually just a view of the issues in different columns.
3. "Workflow"
There are typical workflows.It controls which issues types are used and what the possible transitions among issue types.
4. Assign users to roles
Add developers5. Create Components
Components provides the breakdown of the product.It is optional.
It is useful to have a default assignee for each component.
6. Map status to columns
This is part of the board creation.I found these columns useful for a board created for development:
- Todo - backlog for a given sprint. The tickets are in PM's queue
- Quality Planning Session (QPS) - PM, Dev, and QA have to talk before a ticket is moved into Dev's Queue.
- Dev in Progress - Under development. A ticket should not be in this column too long. if more than a couple of days. The ticket is too big and should have broken into smaller tickets.
- Ready for Test - this is the backlog for QA
- Test in Progress
- Done - No more work from Dev or QA
Note that the status to column mapping is an implicit filter on a board.
The issue statuses that are not mapped will not be shown anywhere on the board.
For example, QA can create their own board to view only the statuses mapped to Ready for Test, Test in Progress, and Done.
7. Board Filter Query
The Filter Query determines which issues will be collected into a board. Typically, the Board filter is based on a project and a set of issue types.
However, I found a good practice is to include the issues assigned to resources that are part of the project team.
project = projectA OR assignee in (member1, member2, member3)
Epic Link, component, label are also good filter criteria.
8. Swimlanes
When you have too many tickets on a board, you can further break it by swimlanes.Each Swimlane can have its own filter criteria.
9. Quick Filter
A very good way to group tickets that are owned by a set of people (teams).This can be used in the standup call.
When you call different people to get the status from them. Filter the board to show only the tickets that are owned by them.
No comments:
Post a Comment