Quick guide to understand what hight performance teams are and an example of how their workflow can be manage using Jira.

1. High performance teams
A quick guide

2. DORA
State of DevOps
reports

3. DORA State of DevOps report
DORA: DevOps Research and Assessment (link)
Founders:
Nicole Forsgren
VP research & strategy GitHub
Gene Kim
Multiple award-winning CTO,
researcher and author

4. DORA State of DevOps report
DORA report measures the performance of teams based on, summarized:
- Deliver frequency:
- High performance: Once a day/week
- Elite performance: Several times a day
- Incidences frequency & time to restore
- High performance: Less than 15% frequency, 1 day to restore
- Elite performance: Less than 15% frequency, 1 hour to restore

7. Performance
disrupters

8. Performance deterioration factors
- Product ownership
- Low research on next steps
- Incomplete knowledge of the product
- Wide and/or abstract stories
- Dependencies
- Department isolation
- Poor prioritization
- Interruptions
- Indicences
- Sudden prioritization changes
- Meetings
- Development process blocks
- Dependencies
- Knowledge silos
- Branch-based development, PRs
- QA in test environments

9. Performance improvement factors
- Product ownership
- Shared big picture of the past, present
and future of the product
- Deep knowledge of the product
- Narrow scoped, well documented user
stories
- Transversal and fluid communication
- Appropriate prioritization
- Minimizing interruptions
- Take actions to minimize incidences
- Minimize meetings
- Meetings have a specific scope and
timebox
- Development process
- Shared ownership of the code
- Trunk-based development
- Testing in production environment
- Continuous learning and application of
best practices

10. High performance
Jira board
example

11. Section: Project
Contains the big picture of the whole project in the form of “Epic” stories.
Backlog
- Ideas under construction
Accepted
- Feasible Epics, in order of prioritization
ToDo
- Epics that have been splitted into User Stories
Doing
- Epics that are under development
Done
- Epics deployed in production

12. Section: Product
Contains the User Stories that are caused by Epics.
Backlog
- Ideas under construction
Accepted
- Feasible User stories: After research and conversations among implied departments, the ideas become feasible User
Stories.
- The User Stories in this column are prioritized but will not be implemented immediately.
ToDo
- User Stories that will be implemented during the current sprint.
- Ideally, the US in this column have been splitted into Technical Tasks.
Doing
- US under construction
Done
- US deployed in production
- If there is a not-blocking incidence related to a deployed US, open an Issue related to the Epic. The Issue is prioritized and
travels from left to right, just like any other US
- It there is a blocking incidence related to a deployed US, open a Bug related to the Epic. Bugs have maximum priority over
any other development, because they are interrupting the service. If the incidence is not interrupting the service, then it is
an Issue, not a Bug.

13. Section: Development
Contains the Technical Tasks that are caused by User Stories.
Backlog
- Technical Task that are being drafted.
Accepted
- Feasible Technical Tasks: The development team meets to split the US into concise steps that
are described in very narrow scoped tasks.
ToDo
- Technical Tasks that will be implemented immediately.
Doing
- Technical Tasks under construction.
Done
- Technical Tasks that have been deployed to production.

14. Thank you!