Unifying Team Processes Using JIRA Wallboards
•Als KEY, PDF herunterladen•
0 gefällt mir•904 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Unifying Team Processes Using JIRA Wallboards
Ähnlich wie Unifying Team Processes Using JIRA Wallboards (20)
Mehr von Atlassian
Mehr von Atlassian (20)
Unifying Team Processes Using JIRA Wallboards
- 3. Unifying Team Processes Using JIRA Wallboards Better Living Through Information Radiators Tony Atkins Senior Support Engineer, Atlassian 2
- 6. 4
- 7. 4
- 8. 5
- 9. Why Wallboards? •Globally distributed team •Shared pool of tickets •Inconsistent processes •“What do I do next?” 5
- 10. 6
- 11. Our Process •Define the Goals •Get the Data •Put It Together •Refine 6
- 13. A wallboard is only useful...
- 14. A wallboard is only useful... ...if it allows you to respond better to the real-world problems you face.
- 15. 8
- 16. Define Goals 8
- 17. 8
- 18. 9
- 19. Get the Data 9
- 20. 9
- 21. 10
- 22. 10
- 23. 10
- 24. 10
- 25. 10
- 26. Does this belong on screen? 10
- 27. Does this belong on screen? What’s the simplest way to show this? 10
- 28. 11
- 29. 11
- 30. 11
- 31. 11
- 32. 12
- 33. 12
- 34. 13
- 35. 13
- 36. Work from the top down 13
- 37. Work from the top down Issues rise over time 13
- 38. 13
- 39. Created 13
- 40. 13 ned Assig Created
- 41. Created ra ge Ave Assig ned 13
- 42. 13
- 43. 13 Assignee TZ Summary Key Clock Help Triage Priority
- 44. 14
- 45. What did this change? 14
- 46. 15
- 47. •Wallboards used by all engineers •Shared understanding of our global work •Shared vocabulary •Better teamwork in each location •Better coordination between locations •Driver of process changes 15
- 48. 16
- 49. How can help? 16
- 50. 17
- 51. 17
- 52. 17
- 53. 17
- 54. 18
- 55. 18
- 56. 18
- 57. 18
- 58. 19
- 59. 19
- 60. 19
- 61. 20
- 62. Nex t: Ti the ps f Ultim rom Wal ate Com lboard peti tion ! Questions? 20
- 63. 21
- 66. “ Wallboards help bring your best practices to life. JIRA and the Wallboard Plugin can give you a big head start: http://atlss.in/wb-plugin ” #summit11 23
Hinweis der Redaktion
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Hi, my name is Tony Atkins. I’m a Senior Support Engineer working in our Amsterdam office. Since I joined Atlassian two years ago, I’ve been handling support cases for JIRA, GreenHopper, Confluence, and JIRA Studio. I’m currently developing plugins for Atlassian products, including self-help tools for customers and tools to help our our support team. \n\nAlmost since my first week at Atlassian, I’ve worked with my colleagues to develop our support wallboards. Today I’m going to tell you a little bit about our experiences.\n\nSo, how many of you are using wallboards with your teams now?\n\nHow many would like to be using wallboards?\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- Some of you may know the term “information radiator” coined by Alistair Cockburn (COH-BURN), in Atlassian, we tend to call them wallboards. In short, they’re large displays that give you a simplified view of key information, and they’re updated in real time.\n\nHere are a few examples off how we use wallboards in Atlassian offices around the world. (click)\n\nWe have a lot of development teams, so you can see wallboards focused on things like build status, burn-down charts, days left. You also see a few boards with red, yellow, and gray, those are the support wallboards that we’ll talk about in just a minute.\n\nEven from this small sample, you can see that some of our work activities (such as standups or smaller meetings) are focused around the wallboard. You can also see that the rest of the time, wallboards sit in the background and radiate information about the health of teams and projects.\n\n\n
- I’m here today to tell you how Wallboards have changed the way we work in Atlassian Support.\n
- I’m here today to tell you how Wallboards have changed the way we work in Atlassian Support.\n
- So, what was the problem?\n\nWe have a rapidly growing global team, and a growing number of customers.\n\n(click) Our global support team (click) works from a single pool of incoming tickets. \n(click) We had processes for handling the pool of tickets, but they were inconsistent between teams. \n\n(click) Even if you understood and followed our best practices, you had to compare information from different screens and do a bit of math in your head to figure out what issues to take next.\n
- So, what was the problem?\n\nWe have a rapidly growing global team, and a growing number of customers.\n\n(click) Our global support team (click) works from a single pool of incoming tickets. \n(click) We had processes for handling the pool of tickets, but they were inconsistent between teams. \n\n(click) Even if you understood and followed our best practices, you had to compare information from different screens and do a bit of math in your head to figure out what issues to take next.\n
- So, what was the problem?\n\nWe have a rapidly growing global team, and a growing number of customers.\n\n(click) Our global support team (click) works from a single pool of incoming tickets. \n(click) We had processes for handling the pool of tickets, but they were inconsistent between teams. \n\n(click) Even if you understood and followed our best practices, you had to compare information from different screens and do a bit of math in your head to figure out what issues to take next.\n
- So, what was the problem?\n\nWe have a rapidly growing global team, and a growing number of customers.\n\n(click) Our global support team (click) works from a single pool of incoming tickets. \n(click) We had processes for handling the pool of tickets, but they were inconsistent between teams. \n\n(click) Even if you understood and followed our best practices, you had to compare information from different screens and do a bit of math in your head to figure out what issues to take next.\n
- So, what was the problem?\n\nWe have a rapidly growing global team, and a growing number of customers.\n\n(click) Our global support team (click) works from a single pool of incoming tickets. \n(click) We had processes for handling the pool of tickets, but they were inconsistent between teams. \n\n(click) Even if you understood and followed our best practices, you had to compare information from different screens and do a bit of math in your head to figure out what issues to take next.\n
- We knew we needed to make a change. Our process was to define the goals, get the data, put it together, and then refine.\n
- We knew we needed to make a change. Our process was to define the goals, get the data, put it together, and then refine.\n
- We knew we needed to make a change. Our process was to define the goals, get the data, put it together, and then refine.\n
- We knew we needed to make a change. Our process was to define the goals, get the data, put it together, and then refine.\n
- We knew we needed to make a change. Our process was to define the goals, get the data, put it together, and then refine.\n
- Let’s start with a reality check. Wallboards are cool, a large display, an obvious bit of “nerd bling” in an IT office, something you show people when they visit. But we don’t need another toy, we need to get work done.\n\n(click) A wallboard is only useful... (pause, click) if it lets you do your job better. (click)\n\n\n
- Let’s start with a reality check. Wallboards are cool, a large display, an obvious bit of “nerd bling” in an IT office, something you show people when they visit. But we don’t need another toy, we need to get work done.\n\n(click) A wallboard is only useful... (pause, click) if it lets you do your job better. (click)\n\n\n
- Let’s start with a reality check. Wallboards are cool, a large display, an obvious bit of “nerd bling” in an IT office, something you show people when they visit. But we don’t need another toy, we need to get work done.\n\n(click) A wallboard is only useful... (pause, click) if it lets you do your job better. (click)\n\n\n
- For Atlassian Support, the goal is to help our customers as quickly as we can, and to provide the same level of service around the clock and across the globe.\n\nWe need for the wallboard to answer key questions, to provide key pieces of information more quickly and consistently than anyone could do on their own. We need for the wallboard to embody our best thinking about our problems and process, and put that in front of everyone real-time.\n\n\n
- For Atlassian Support, the goal is to help our customers as quickly as we can, and to provide the same level of service around the clock and across the globe.\n\nWe need for the wallboard to answer key questions, to provide key pieces of information more quickly and consistently than anyone could do on their own. We need for the wallboard to embody our best thinking about our problems and process, and put that in front of everyone real-time.\n\n\n
- So, now is the time to brainstorm. Sit down and think of every piece of information that’s useful in meeting your goal. For Support, in order to answer the question “What case should I take next?”, an engineer needs to know:\n\nIs the case already being handled?\nHow long has the case been waiting?\nWhat’s the impact of the problem reported?\nWhere is the customer coming from?\nWhat’s the case about?\n\nWe needed to find data to answer each of those questions. In our case we used JIRA’s existing data and custom fields (I’ll talk more about that in a bit).\n
- So, now is the time to brainstorm. Sit down and think of every piece of information that’s useful in meeting your goal. For Support, in order to answer the question “What case should I take next?”, an engineer needs to know:\n\nIs the case already being handled?\nHow long has the case been waiting?\nWhat’s the impact of the problem reported?\nWhere is the customer coming from?\nWhat’s the case about?\n\nWe needed to find data to answer each of those questions. In our case we used JIRA’s existing data and custom fields (I’ll talk more about that in a bit).\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- We know our goals, which helps to set the scope, but we also have to keep a few practical concerns in mind.\n\nWe’re going to be displaying this on a large monitor (click), and there’s an upper limit on how big we can go. Even if we spend $10,000 on a 70 inch monitor or project an image on a whole wall (click)\n\nPeople are still going to be viewing this from across the room. There are limits to how small you can make text, numbers, graphs, and images before people lose the ability to see them at a distance.\n\nIn short, we’re only going to be able to display so much information and no more.\n\nFor each piece of information, ask yourself: “Does this have to be on-screen?” (click)\n\nSome information is only needed to control the way other information is displayed. For example, in our case, we have a “show on wallboard” custom field that lets engineers take their issue off the wallboard temporarily.\n\nYou should also ask: “What’s the simplest way to display the information?” (click)\n\nSome information (like the issue key) needs to be displayed in full. Some information (like the summary) can be limited to a fixed length. Other information (like urgency and priority) can be conveyed using color, icons, or graphs.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- When you’re first getting started (click), it’s unlikely your first attempt will be all that usable (click). Over time, you refine what you have until you have something clear (click).\n\nBut it’s not just about visuals. Remember, the wallboard is a tool to meet the goal.\n\nIf your goals change, the wallboard must change. You need to keep your process lightweight enough that you can respond to process changes fairly quickly. The last thing you want is for your process to be driven by your wallboard rather than the other way around.\n\nAlso, in order for the wallboard to be a good tool, your team needs to understand and use it. If the team doesn’t understand the wallboard, keep working with them and with the wallboard. Add help features.\n\nIt should be natural to use the wallboard during team meetings, daily standups and other processes. At first, you might have to push a bit and remind people, but as you go, find out why people aren’t using the wallboard, and remove or improve things that aren’t working. \n\nOnce you get the formula right, you won’t have to push, but fair warning, once people get a sense of how useful a wallboard is, they’ll have tons of ideas about how to make it better.\n
- And now, let’s look at the end result of all our work with the Support Wallboards.\n
- And now, let’s look at the end result of all our work with the Support Wallboards.\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- So, let’s take a look at our Support Wallboard (click).\n\nThere’s a lot here, let’s go through it in parts. First, let’s talk about the colors. Red indicates that an issue needs attention immediately, that we’re already late. Yellow indicates that an issue needs attention soon, but slightly less urgently. Gray indicates that an issue has only recently come in, and that we have more time to deal with it.\n\nNext, let’s talk about the order in which issues are displayed (click). The most urgent issues are always displayed at the top of the board, and engineers work from the top to the bottom of the board. \n\nThis isn’t a static view. Issues move up the board over time (click). The longer an issue stays on the board, the higher up it appears. The higher the priority of the issue, the higher it starts, and the more quickly it moves up the wallboard. Problems with mission-critical systems start out at the top of the wallboard and stay there. Usage questions or other lower priority issues start close to the bottom, and move up over time.\n\nSo with that out of the way, let’s work our way down the rest of the wallboard. (click) The load bar displays today’s workload and our historical averages, all at a glance. We have the number of incoming issues (click), the number of assigned issued (click), that is, issues that have been picked up by an engineer. We also have an average (click) for both input and output. With this simple bar, we can tell a few key things. We can tell if it’s a high or low-volume day. We can tell if we’re keeping up with the load. This gives us a quick way to know if we need to call for additional help, or if we have time for a few team members to cross-train during lower-volume days.\n\nNow let’s look at the meat of the wallboard, a single row in the table (click). \n\nThis is all the screen real estate each issue gets, so we did a lot to compact the display (click). From left to right, we have an icon bar, with indicators for priority, among other things. We also have the clock, which lets us compare the time this customer has spent waiting to the rest of the customers in line. \n\nWe have the issue key and summary, which are useful to let people discuss issues, as in “I’m going to take care of the case about JIRA going slow”. \n\n\nWe also have the timezone that the customer is in, which helps us get a sense of whether they’re likely to be online, whether we need to hand them off to another team at the end of our shift, et cetera. \n\nFinally, we have the assignee for the case. If the field is blank, the case needs to be picked up. If there’s an assignee, we check with that person to see if they need help before moving on to the next case.\n\nSo, that’s our wallboard. At a glance, we can tell what’s next, who’s taking what, and how we’re doing for the day.\n\n\n
- \n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- (click)\nWe’ve been working on our wallboards for about two years now. In addition to the wall-mounted displays, we also have “personal wallboards” which use the same logic in the dashboards everyone views on their screen. Everyone on our team uses the wallboard every day.\n\nThe wallboard embodies our best practices, and to get to that point we’ve had to really talk through our process and agree on how we need to handle things.\n\nBecause we’re all looking at the same boards, we’ve developed a common vocabulary around handling issues. When someone says “Can someone ping Tony about the L1 JIRA ticket he’s working on?”, everyone knows what they mean.\n\nWe use the wallboards within local teams to coordinate work, you can see our SF team and Sydney teams have their standups around the wallboard. On the EMEA shift, we take screen shots of the wallboards at the end of each day to make a note of how we did.\n\nWe also use the wallboard to coordinate between offices. In the Amsterdam office, for example, we have handover meetings, where we review what’s left on the wallboard and talk through what needs to be done. \n\nNow that we have wallboards in place everywhere, we use them to drive changes. If we build new teams with new processes, we talk through what changes we need in the wallboards to support that. If we find gaps in our process, we talk about ways to use the wallboards to close those gaps, for example keeping track of engineers who are overwhelmed and stepping in when their customers have been waiting too long. \n\nThe wallboard responds to our changes, and helps make change possible.\n\n
- We built our wallboards on top of support.atlassian.com, the JIRA instance used by Atlassian Support. I’d like to take the last few minutes to go through how we did that, and how you can use JIRA to build your own wallboards.\n
- We built our wallboards on top of support.atlassian.com, the JIRA instance used by Atlassian Support. I’d like to take the last few minutes to go through how we did that, and how you can use JIRA to build your own wallboards.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, let’s say one of your gadgets contains information about one or more tickets in JIRA. You need some way to keep track of the right data for each issue, and JIRA provides fields to do just that.\n\nFirst (click), we have the built-in fields, things like assignee, summary, and priority. We use each of these in our wallboard.\n\nThe next source of data is custom fields (click), which are user-defined fields. There are built in custom fields for users, text, radio buttons, drop-down lists. For our wallboards, for example, we use a built-in text custom field to keep track of the timezone each customer is coming from.\n\nThere are also custom fields provides by plugins (click). For these, we have a choice of either using an existing plugin (click) or writing our own custom plugin (click) using the Atlassian SDK.\n\nAs an example, we use a plugin written for our support site to keep track of the first response date, the time that an engineer first gets in touch with the customer.\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- So, to start using the Wallboard Plugin, you need a JIRA dashboard and some content.\n\nJIRA and Confluence both export content using Open Social gadgets (click) , and the Dashboard can display gadgets. You can bring in content from JIRA (click), Confluence (click), or other Atlassian products (pause). You can pull from a library of existing external gadgets used in sites like iGoogle. You can even write your own Open Social gadgets and display them in a JIRA dashboard. The simplest gadgets are just HTML and Javascript, so the learning curve is lower than a full JIRA plugin.\n\nOnce you have a few gadgets, you can use put them together in a JIRA dashboard(click).\n
- Once we have all of our content in a dashboard, we already have a lot. In Support, each of our engineers uses the dashboard every day. The only thing we needed beyond that was a way to present it on screen. (click)\n\nThe wallboards I showed you earlier are displayed by the JIRA Wallboard Plugin, which does a few key things to a standard JIRA dashboard. (click)\n\nFirst, it removes the navigation bar, header and footer, and the gadget title bar from JIRA. When you’re fighting for a few extra square inches, this really helps. It also switches to a different style sheet, with a black background.\n\nSo, you’ve got a dashboard on a large screen. With just that, you can refresh each part of the page, but you can only load the same content over and over again. Here’s where the Wallboard Plugin goes even further... (click)\n\nYou can define multiple gadgets in the same dashboard column that use the same label color, and the Wallboard Plugin will rotate between those gadgets and display them. (click).\n\nSuddenly, you’ve gone from a fixed set of content that fits on a single screen to as much content as you need, and you can just load a single page and let it run.\n
- Once we have all of our content in a dashboard, we already have a lot. In Support, each of our engineers uses the dashboard every day. The only thing we needed beyond that was a way to present it on screen. (click)\n\nThe wallboards I showed you earlier are displayed by the JIRA Wallboard Plugin, which does a few key things to a standard JIRA dashboard. (click)\n\nFirst, it removes the navigation bar, header and footer, and the gadget title bar from JIRA. When you’re fighting for a few extra square inches, this really helps. It also switches to a different style sheet, with a black background.\n\nSo, you’ve got a dashboard on a large screen. With just that, you can refresh each part of the page, but you can only load the same content over and over again. Here’s where the Wallboard Plugin goes even further... (click)\n\nYou can define multiple gadgets in the same dashboard column that use the same label color, and the Wallboard Plugin will rotate between those gadgets and display them. (click).\n\nSuddenly, you’ve gone from a fixed set of content that fits on a single screen to as much content as you need, and you can just load a single page and let it run.\n
- Once we have all of our content in a dashboard, we already have a lot. In Support, each of our engineers uses the dashboard every day. The only thing we needed beyond that was a way to present it on screen. (click)\n\nThe wallboards I showed you earlier are displayed by the JIRA Wallboard Plugin, which does a few key things to a standard JIRA dashboard. (click)\n\nFirst, it removes the navigation bar, header and footer, and the gadget title bar from JIRA. When you’re fighting for a few extra square inches, this really helps. It also switches to a different style sheet, with a black background.\n\nSo, you’ve got a dashboard on a large screen. With just that, you can refresh each part of the page, but you can only load the same content over and over again. Here’s where the Wallboard Plugin goes even further... (click)\n\nYou can define multiple gadgets in the same dashboard column that use the same label color, and the Wallboard Plugin will rotate between those gadgets and display them. (click).\n\nSuddenly, you’ve gone from a fixed set of content that fits on a single screen to as much content as you need, and you can just load a single page and let it run.\n
- Once we have all of our content in a dashboard, we already have a lot. In Support, each of our engineers uses the dashboard every day. The only thing we needed beyond that was a way to present it on screen. (click)\n\nThe wallboards I showed you earlier are displayed by the JIRA Wallboard Plugin, which does a few key things to a standard JIRA dashboard. (click)\n\nFirst, it removes the navigation bar, header and footer, and the gadget title bar from JIRA. When you’re fighting for a few extra square inches, this really helps. It also switches to a different style sheet, with a black background.\n\nSo, you’ve got a dashboard on a large screen. With just that, you can refresh each part of the page, but you can only load the same content over and over again. Here’s where the Wallboard Plugin goes even further... (click)\n\nYou can define multiple gadgets in the same dashboard column that use the same label color, and the Wallboard Plugin will rotate between those gadgets and display them. (click).\n\nSuddenly, you’ve gone from a fixed set of content that fits on a single screen to as much content as you need, and you can just load a single page and let it run.\n
- Once we have all of our content in a dashboard, we already have a lot. In Support, each of our engineers uses the dashboard every day. The only thing we needed beyond that was a way to present it on screen. (click)\n\nThe wallboards I showed you earlier are displayed by the JIRA Wallboard Plugin, which does a few key things to a standard JIRA dashboard. (click)\n\nFirst, it removes the navigation bar, header and footer, and the gadget title bar from JIRA. When you’re fighting for a few extra square inches, this really helps. It also switches to a different style sheet, with a black background.\n\nSo, you’ve got a dashboard on a large screen. With just that, you can refresh each part of the page, but you can only load the same content over and over again. Here’s where the Wallboard Plugin goes even further... (click)\n\nYou can define multiple gadgets in the same dashboard column that use the same label color, and the Wallboard Plugin will rotate between those gadgets and display them. (click).\n\nSuddenly, you’ve gone from a fixed set of content that fits on a single screen to as much content as you need, and you can just load a single page and let it run.\n
- Once we have all of our content in a dashboard, we already have a lot. In Support, each of our engineers uses the dashboard every day. The only thing we needed beyond that was a way to present it on screen. (click)\n\nThe wallboards I showed you earlier are displayed by the JIRA Wallboard Plugin, which does a few key things to a standard JIRA dashboard. (click)\n\nFirst, it removes the navigation bar, header and footer, and the gadget title bar from JIRA. When you’re fighting for a few extra square inches, this really helps. It also switches to a different style sheet, with a black background.\n\nSo, you’ve got a dashboard on a large screen. With just that, you can refresh each part of the page, but you can only load the same content over and over again. Here’s where the Wallboard Plugin goes even further... (click)\n\nYou can define multiple gadgets in the same dashboard column that use the same label color, and the Wallboard Plugin will rotate between those gadgets and display them. (click).\n\nSuddenly, you’ve gone from a fixed set of content that fits on a single screen to as much content as you need, and you can just load a single page and let it run.\n
- In case we run out of time, I wanted to mention that up next in this room, we have tips from the Ultimate Wallboard competition, where you’ll see lots of other examples of wallboards.\n
- In case we run out of time, I wanted to mention that up next in this room, we have tips from the Ultimate Wallboard competition, where you’ll see lots of other examples of wallboards.\n
- In case we run out of time, I wanted to mention that up next in this room, we have tips from the Ultimate Wallboard competition, where you’ll see lots of other examples of wallboards.\n
- In case we run out of time, I wanted to mention that up next in this room, we have tips from the Ultimate Wallboard competition, where you’ll see lots of other examples of wallboards.\n
- \n
- \n
- \n
- \n
- So that’s the problem we faced, and the process we used to come up with our JIRA wallboards. I hope you’ve found it useful, and I’m happy to answer your questions. But first, (click)\n