The document discusses how to create effective dashboards for project visibility and productivity. It explains that good dashboards should have a clear purpose, display the most important information prominently, limit the amount of information, and diversify the types of information. Examples of useful widgets and filters for an agile team dashboard are provided, including impediments, burndowns, defect ratios, open defects, and work in progress charts. Additional resources for setting up these dashboards are referenced.
Introduction to JIRA & Agile Project ManagementDan Chuparkoff
This document provides an introduction to using JIRA for agile project management. It discusses key concepts like defining tasks, estimating task effort in story points, and using JIRA's agile tools like boards and burndowns. Screenshots show how to create and manage tasks in JIRA's different modes for Scrum and Kanban workflows.
Whether your business is a small, fast-growing agile shop, or a larger company that is trying to adopt agile methodologies, success hinges on a proper foundation of roles, responsibilities, and processes. In this talk, we’ll cover how Trulia tackles these areas, and discuss how JIRA Agile helped us expand our agile cycles.
Kickass Agile Development - Agile & Beyond ConferenceDan Chuparkoff
Watch Dan Chuparkoff as he shares some of the secrets to kick-ass software development at Atlassian. He gives us a glimpse at a new Agile paradigm. Feedback cycles are short, code quality is awesome, and customers get the features they lust after. Hear how Atlassian uses pull-requests for better code quality; collaborates fast to develop ideas; avoids meetings; tightens feedback loops to fail fast; shortens release cycles and work together happily from different corners of the globe. Sound like paradise? It is!
Heavenly hell – automated tests at scale wojciech seligaAtlassian
The document summarizes Atlassian's journey to improve their automated test suite over 2.5 years. They had over 20,000 slow and fragile tests that resulted in dispirited developers accepting failures as normal. Through efforts like restructuring tests, parallelizing execution, removing flaky tests, and splitting the codebase into modules, they were able to reduce build times from over 2 hours to under 1 hour and make passes the norm. Continuous measurement, removing technical debt, and prioritizing test performance were key to their success in improving development feedback loops.
Building and Supporting Billion Dollar Ships with JIRA - Greg WarnerAtlassian
Learn how JIRA is being used outside of the traditional software development domain. See how BAE builds, delivers, and supports billion dollar ships for the Australian Defense Force, all while saving millions in operational costs in the first year alone. Greg will also discuss the migration of more that 475,000 pieces of metadata using the REST API.
This document provides an overview of Scrum, an agile software development framework. It discusses key Scrum concepts like the agile manifesto, roles, ceremonies, and artifacts. The Scrum framework uses short iterations called sprints to incrementally develop working software. It emphasizes self-organizing cross-functional teams, prioritized backlogs, and frequent inspection and adaptation to respond to changes. Surveys find that most organizations using Scrum see benefits like increased productivity, collaboration, and satisfaction over traditional waterfall approaches.
Spiking Your Way to Improved Agile Development - Anatoli KazatchkovAtlassian
New feature development in agile should almost always start with a spike. Spikes help to define feature scope, uncover technical unknowns, and provide accurate estimates. In this session we will cover how to introduce spikes into your development cycles and show how Atlassian defines spike goals, focuses spike efforts, and makes feature development more effective.
Agile for the Masses: How to Make Any Team More Effective - John WetenhallAtlassian
In this talk, we will demonstrate how Atlassian's Collaboration Product Marketing Team has adopted the agile methodology. We'll cover how we think about "shipping products," how we plan our work with quarterly goals and biweekly sprints, and how we reflect with retrospectives.
Introduction to JIRA & Agile Project ManagementDan Chuparkoff
This document provides an introduction to using JIRA for agile project management. It discusses key concepts like defining tasks, estimating task effort in story points, and using JIRA's agile tools like boards and burndowns. Screenshots show how to create and manage tasks in JIRA's different modes for Scrum and Kanban workflows.
Whether your business is a small, fast-growing agile shop, or a larger company that is trying to adopt agile methodologies, success hinges on a proper foundation of roles, responsibilities, and processes. In this talk, we’ll cover how Trulia tackles these areas, and discuss how JIRA Agile helped us expand our agile cycles.
Kickass Agile Development - Agile & Beyond ConferenceDan Chuparkoff
Watch Dan Chuparkoff as he shares some of the secrets to kick-ass software development at Atlassian. He gives us a glimpse at a new Agile paradigm. Feedback cycles are short, code quality is awesome, and customers get the features they lust after. Hear how Atlassian uses pull-requests for better code quality; collaborates fast to develop ideas; avoids meetings; tightens feedback loops to fail fast; shortens release cycles and work together happily from different corners of the globe. Sound like paradise? It is!
Heavenly hell – automated tests at scale wojciech seligaAtlassian
The document summarizes Atlassian's journey to improve their automated test suite over 2.5 years. They had over 20,000 slow and fragile tests that resulted in dispirited developers accepting failures as normal. Through efforts like restructuring tests, parallelizing execution, removing flaky tests, and splitting the codebase into modules, they were able to reduce build times from over 2 hours to under 1 hour and make passes the norm. Continuous measurement, removing technical debt, and prioritizing test performance were key to their success in improving development feedback loops.
Building and Supporting Billion Dollar Ships with JIRA - Greg WarnerAtlassian
Learn how JIRA is being used outside of the traditional software development domain. See how BAE builds, delivers, and supports billion dollar ships for the Australian Defense Force, all while saving millions in operational costs in the first year alone. Greg will also discuss the migration of more that 475,000 pieces of metadata using the REST API.
This document provides an overview of Scrum, an agile software development framework. It discusses key Scrum concepts like the agile manifesto, roles, ceremonies, and artifacts. The Scrum framework uses short iterations called sprints to incrementally develop working software. It emphasizes self-organizing cross-functional teams, prioritized backlogs, and frequent inspection and adaptation to respond to changes. Surveys find that most organizations using Scrum see benefits like increased productivity, collaboration, and satisfaction over traditional waterfall approaches.
Spiking Your Way to Improved Agile Development - Anatoli KazatchkovAtlassian
New feature development in agile should almost always start with a spike. Spikes help to define feature scope, uncover technical unknowns, and provide accurate estimates. In this session we will cover how to introduce spikes into your development cycles and show how Atlassian defines spike goals, focuses spike efforts, and makes feature development more effective.
Agile for the Masses: How to Make Any Team More Effective - John WetenhallAtlassian
In this talk, we will demonstrate how Atlassian's Collaboration Product Marketing Team has adopted the agile methodology. We'll cover how we think about "shipping products," how we plan our work with quarterly goals and biweekly sprints, and how we reflect with retrospectives.
Design product by developing empathy for your users and understanding the tasks they are trying to accomplish. How do I know what to design? When do I test it? When is a design complete?
This talk will present iterative design and testing method that is light weight and can significantly improve your product design.
This document provides a framework for planning and executing a project called LockerPaLooza 2013. It outlines key questions to consider around the desired outcome, purpose and required actions of the project. The framework also includes steps to capture all necessary actions, measure and evaluate progress, then celebrate upon completion.
Lean Lego Game - Agile Vancouver 2012 - Noel PullenNoel Pullen
Doing > Talking. This exercise will introduce concepts of Push vs. Pull, Kanban (bottlenecks, cycle time, work-in-process limits, idle/slack time, flow), Continuous Improvement (Kaizen), and Waste
In this session you will work on a small Lego production line, experience production problems and apply Lean practices to overcome them. This session will just scratch the surface of Lean and is best suited for Lean/Agile beginners or intermediates. Those currently practicing Scrum, Waterfall, or any other non-Kanban method of software development will benefit.
Lean concepts covered: Waste, Push and Pull Systems, Kanban, System Thinking, Work Cells, Kaizen
Credit: Danilo Sato and Francisco Trindade
This document provides an overview of Scrum, an agile framework for managing product development. It discusses the Scrum roles of Product Owner, Team, and Scrum Master. The key Scrum ceremonies are planning, daily stand-ups, sprint reviews, and retrospectives. Scrum uses short iterations called sprints to incrementally deliver working software. The document recommends starting with a short initial sprint length and identifying the Product Owner, Scrum Master, and cross-functional Team.
Internal presentation to sum up what it is (and what it is not) Agile.
It was designed as an introduction to the other presentation called "Agile methodologies in short": http://www.slideshare.net/lalaianohies/agile-methodologies-in-short
This document provides an introduction to agile development methods over the course of 1.5 hours. It begins with background on the presenter and an outline of topics to be covered, including an overview of traditional waterfall development practices, lean software development principles, agile principles and the Scrum framework. Key aspects of Scrum like roles, meetings, estimations and visualizing work are defined. Kanban principles and how it compares to Scrum are also introduced. The document emphasizes adopting agile practices to improve productivity, deliver value frequently and welcome changing requirements.
modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.
Modern agile methods are defined by four guiding principles:
- Make people awesome
- Make safety a prerequisite
- Experiment & learn rapidly
- Deliver value continuously
Overcome the 6 Antipatterns of Agile AdoptionAgile Velocity
Presented at Global Scrum Gathering Orlando 2016
Because of benefits like predictability, better quality of products, and faster delivery, many companies have adopted or in the process of adopting Agile. However, there are challenges.
David Hawks, CST and Agile Evangelist, explains the common antipatterns of Agile adoption.
The document discusses the principles behind the Agile Manifesto and provides examples of patterns and anti-patterns related to adopting Agile practices. It begins by listing the 12 principles from the Agile Manifesto, including delivering working software frequently and valuing customer collaboration over contract negotiation. The document then analyzes scenarios to determine whether team decisions align with or contradict Agile principles, and suggests more aligned approaches when needed.
Project Managers often face an identity crisis when companies transition to agile: either become a scrum master, move to another role entirely, or another company! This discussion will demonstrate how project management can not only co-exist with your agile process, but thrive. Plus, you'll learn how Gilt blends agile principles with traditional project management techniques to bring their strategic initiatives to life.
This document discusses different levels of Scrum implementation from Level 0 (Waterfall) to Level 3 (Automation). It provides examples of characteristics and behaviors typical of each level. Level 0 focuses on requirements, design, code, and test phases with code freeze and hardening periods. Level 1 incorporates some Scrum terminology but still behaves largely like Waterfall. Level 2 starts adopting a more collaborative mindset within fixed-length sprints. Level 3 fully embraces Agile principles with self-organizing teams, test-driven development, and continuous improvement. Guidelines are provided for progressing through the levels over time with management commitment and patience.
Vladimirs Ivanovs - Creating children book in 45 minutes thanks to ScrumVladimirs Ivanovs
Creating a book is not a simple project however applying Agile principles to the process might make it much more easier to manage and give you better results. During the workshop we will create a children's book of "Goldilocks and the three bears" by using Scrum techniques. You will get familiar with Product Backlog, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. You will also stay awake as workshop requires your active participation, gives ability to have fun and engage your creativity.
This workshop have been delivered by me at such locations as Agile Tour Vilnius 2013, IPMA Project Management congress 2013 in Dubrovnik, StartUp Latvia and Agile Latvia, telecom Orange Polska and IPMA Polska workshop. More to come ;)
Another name for this workshop is "Goldilocks and the Three Bears". A nice workshop to feel the agile process in action.
This document provides an overview of using Scrum for video game development. It discusses how Agile and Scrum practices can help video game teams iterate quickly to find the fun, deliver working features frequently, and get early feedback. The key aspects of Scrum covered include sprint planning, daily standups, sprint reviews, retrospectives, and managing product and sprint backlogs. The document advocates adopting Scrum to improve quality, engage the team, and better address uncertainty compared to traditional "waterfall" development.
The document discusses CallPlus' journey to adopting the Agile development methodology of Scrum. It describes their initial impressions of Agile and forming a Scrum development team. With executive approval, they attempted their first Scrum but needed professional help. After investing in training and coaching, they started having success with Scrum by completing 100% of their sprint goals. The document attributes their Scrum success to having an open mindset, willingness to learn from mistakes, support from business leaders, and engaged developers.
To help teams make effective day-to-day decisions that support Lean-Agile principles, we’ve created a simple yardstick at LeanKit called FSGD — Frequent, Small, Good, Decoupled.
Easy to remember and apply, “Fizz Good” is a way of breaking down work that reduces the need for cross-team scheduling, estimation and coordination. The results? Faster delivery of customer value.
In this webinar, Daniel Norton, co-founder and Chief Mobile Officer at LeanKit, explains how FSGD can help your organization and how to get started.
This document provides an overview of concepts related to practical Scrum. It discusses roles like the Product Owner and how they define features, priorities, and work for each iteration. It covers topics like requirements gathering, user story writing, estimating effort using planning poker, calculating team velocity, and long-term release planning. The document also explains Scrum ceremonies like sprint planning, daily stand-ups, sprint reviews, and retrospectives. Finally, it discusses agile engineering practices like pair programming, test-driven development, refactoring, and continuous integration.
The document discusses how the Scrum framework can be applied to game development. It explains that Scrum is an agile development process where self-organizing teams work in sprints to deliver working software every 2-4 weeks based on priorities set by business stakeholders. It then outlines the typical Scrum ceremonies like sprint planning, daily stand-ups, and retrospectives. Finally, it poses several questions about how requirements, roadmaps, designers, testers, bugs, changes to requirements, and large team sizes are handled when using Scrum for game development projects.
This document provides an overview of practical scrum. It discusses the three scrum roles of product owner, scrum master, and team. It also describes the four scrum ceremonies and three artifacts. Key principles of scrum include self-organizing teams, empirical process, and delivering working software frequently. The document contrasts command-and-control with self-management and explains how the manager's role changes in an agile environment.
The document summarizes findings from a survey on continuous delivery practices. The survey found that while 81% of organizations practiced some form of continuous delivery for their code, only around 50% did so for their databases. Key challenges included a lack of database version control, manual scripting processes prone to errors, and a lack of trust and communication between developers and database administrators. Adopting database version control, automated deployments informed by version control data, and making DBAs responsible for continuous delivery processes could help address these challenges and barriers to fully implementing continuous delivery for databases.
Design product by developing empathy for your users and understanding the tasks they are trying to accomplish. How do I know what to design? When do I test it? When is a design complete?
This talk will present iterative design and testing method that is light weight and can significantly improve your product design.
This document provides a framework for planning and executing a project called LockerPaLooza 2013. It outlines key questions to consider around the desired outcome, purpose and required actions of the project. The framework also includes steps to capture all necessary actions, measure and evaluate progress, then celebrate upon completion.
Lean Lego Game - Agile Vancouver 2012 - Noel PullenNoel Pullen
Doing > Talking. This exercise will introduce concepts of Push vs. Pull, Kanban (bottlenecks, cycle time, work-in-process limits, idle/slack time, flow), Continuous Improvement (Kaizen), and Waste
In this session you will work on a small Lego production line, experience production problems and apply Lean practices to overcome them. This session will just scratch the surface of Lean and is best suited for Lean/Agile beginners or intermediates. Those currently practicing Scrum, Waterfall, or any other non-Kanban method of software development will benefit.
Lean concepts covered: Waste, Push and Pull Systems, Kanban, System Thinking, Work Cells, Kaizen
Credit: Danilo Sato and Francisco Trindade
This document provides an overview of Scrum, an agile framework for managing product development. It discusses the Scrum roles of Product Owner, Team, and Scrum Master. The key Scrum ceremonies are planning, daily stand-ups, sprint reviews, and retrospectives. Scrum uses short iterations called sprints to incrementally deliver working software. The document recommends starting with a short initial sprint length and identifying the Product Owner, Scrum Master, and cross-functional Team.
Internal presentation to sum up what it is (and what it is not) Agile.
It was designed as an introduction to the other presentation called "Agile methodologies in short": http://www.slideshare.net/lalaianohies/agile-methodologies-in-short
This document provides an introduction to agile development methods over the course of 1.5 hours. It begins with background on the presenter and an outline of topics to be covered, including an overview of traditional waterfall development practices, lean software development principles, agile principles and the Scrum framework. Key aspects of Scrum like roles, meetings, estimations and visualizing work are defined. Kanban principles and how it compares to Scrum are also introduced. The document emphasizes adopting agile practices to improve productivity, deliver value frequently and welcome changing requirements.
modern approaches share a focus on producing exceptional outcomes and growing an outstanding culture. Today, it makes far more sense to bypass antiquated agility in favor of modern approaches.
Modern agile methods are defined by four guiding principles:
- Make people awesome
- Make safety a prerequisite
- Experiment & learn rapidly
- Deliver value continuously
Overcome the 6 Antipatterns of Agile AdoptionAgile Velocity
Presented at Global Scrum Gathering Orlando 2016
Because of benefits like predictability, better quality of products, and faster delivery, many companies have adopted or in the process of adopting Agile. However, there are challenges.
David Hawks, CST and Agile Evangelist, explains the common antipatterns of Agile adoption.
The document discusses the principles behind the Agile Manifesto and provides examples of patterns and anti-patterns related to adopting Agile practices. It begins by listing the 12 principles from the Agile Manifesto, including delivering working software frequently and valuing customer collaboration over contract negotiation. The document then analyzes scenarios to determine whether team decisions align with or contradict Agile principles, and suggests more aligned approaches when needed.
Project Managers often face an identity crisis when companies transition to agile: either become a scrum master, move to another role entirely, or another company! This discussion will demonstrate how project management can not only co-exist with your agile process, but thrive. Plus, you'll learn how Gilt blends agile principles with traditional project management techniques to bring their strategic initiatives to life.
This document discusses different levels of Scrum implementation from Level 0 (Waterfall) to Level 3 (Automation). It provides examples of characteristics and behaviors typical of each level. Level 0 focuses on requirements, design, code, and test phases with code freeze and hardening periods. Level 1 incorporates some Scrum terminology but still behaves largely like Waterfall. Level 2 starts adopting a more collaborative mindset within fixed-length sprints. Level 3 fully embraces Agile principles with self-organizing teams, test-driven development, and continuous improvement. Guidelines are provided for progressing through the levels over time with management commitment and patience.
Vladimirs Ivanovs - Creating children book in 45 minutes thanks to ScrumVladimirs Ivanovs
Creating a book is not a simple project however applying Agile principles to the process might make it much more easier to manage and give you better results. During the workshop we will create a children's book of "Goldilocks and the three bears" by using Scrum techniques. You will get familiar with Product Backlog, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. You will also stay awake as workshop requires your active participation, gives ability to have fun and engage your creativity.
This workshop have been delivered by me at such locations as Agile Tour Vilnius 2013, IPMA Project Management congress 2013 in Dubrovnik, StartUp Latvia and Agile Latvia, telecom Orange Polska and IPMA Polska workshop. More to come ;)
Another name for this workshop is "Goldilocks and the Three Bears". A nice workshop to feel the agile process in action.
This document provides an overview of using Scrum for video game development. It discusses how Agile and Scrum practices can help video game teams iterate quickly to find the fun, deliver working features frequently, and get early feedback. The key aspects of Scrum covered include sprint planning, daily standups, sprint reviews, retrospectives, and managing product and sprint backlogs. The document advocates adopting Scrum to improve quality, engage the team, and better address uncertainty compared to traditional "waterfall" development.
The document discusses CallPlus' journey to adopting the Agile development methodology of Scrum. It describes their initial impressions of Agile and forming a Scrum development team. With executive approval, they attempted their first Scrum but needed professional help. After investing in training and coaching, they started having success with Scrum by completing 100% of their sprint goals. The document attributes their Scrum success to having an open mindset, willingness to learn from mistakes, support from business leaders, and engaged developers.
To help teams make effective day-to-day decisions that support Lean-Agile principles, we’ve created a simple yardstick at LeanKit called FSGD — Frequent, Small, Good, Decoupled.
Easy to remember and apply, “Fizz Good” is a way of breaking down work that reduces the need for cross-team scheduling, estimation and coordination. The results? Faster delivery of customer value.
In this webinar, Daniel Norton, co-founder and Chief Mobile Officer at LeanKit, explains how FSGD can help your organization and how to get started.
This document provides an overview of concepts related to practical Scrum. It discusses roles like the Product Owner and how they define features, priorities, and work for each iteration. It covers topics like requirements gathering, user story writing, estimating effort using planning poker, calculating team velocity, and long-term release planning. The document also explains Scrum ceremonies like sprint planning, daily stand-ups, sprint reviews, and retrospectives. Finally, it discusses agile engineering practices like pair programming, test-driven development, refactoring, and continuous integration.
The document discusses how the Scrum framework can be applied to game development. It explains that Scrum is an agile development process where self-organizing teams work in sprints to deliver working software every 2-4 weeks based on priorities set by business stakeholders. It then outlines the typical Scrum ceremonies like sprint planning, daily stand-ups, and retrospectives. Finally, it poses several questions about how requirements, roadmaps, designers, testers, bugs, changes to requirements, and large team sizes are handled when using Scrum for game development projects.
This document provides an overview of practical scrum. It discusses the three scrum roles of product owner, scrum master, and team. It also describes the four scrum ceremonies and three artifacts. Key principles of scrum include self-organizing teams, empirical process, and delivering working software frequently. The document contrasts command-and-control with self-management and explains how the manager's role changes in an agile environment.
The document summarizes findings from a survey on continuous delivery practices. The survey found that while 81% of organizations practiced some form of continuous delivery for their code, only around 50% did so for their databases. Key challenges included a lack of database version control, manual scripting processes prone to errors, and a lack of trust and communication between developers and database administrators. Adopting database version control, automated deployments informed by version control data, and making DBAs responsible for continuous delivery processes could help address these challenges and barriers to fully implementing continuous delivery for databases.
Monitoring Cassandra: Don't Miss a Thing (Alain Rodriguez, The Last Pickle) |...DataStax
Monitoring is critical to successfully running Apache Cassandra in production. Creating a comprehensive and insightful set of dashboards requires a deep knowledge of Cassandra internals that can be intimidating. Everyone however can benefit from knowing where to start looking and why. So that the next time there is a problem you have the right metrics and knowing which dashboards to look at.
In this talk Alain Rodriguez, Consultant at The Last Pickle, will discuss what to monitor in Apache Cassandra, how, and why. He will present examples from commercial products such as DataDog, and open source systems like Grafana.
About the Speaker
Alain Rodriguez Consultant, The Last Pickle
Alain has been working with Apache Cassandra since version 0.8. He was the first Engineer at teads.tv which had grown to 400+ employees by the time he left. During his time at Teads Alain managed and scaled Cassandra clusters across multiple AWS Regions, fully on his own, taking care of the data modeling as well as the troubleshooting and tuning. Alain frequently contributes to the Apache Cassandra users mailing list.
Boris Hinzer provides an overview of Agile and Scrum concepts and practices. He discusses the four values and twelve principles of Agile, as well as the roles, artifacts, and events that are part of Scrum such as the Product Owner, Development Team, product backlog, sprints, sprint planning, daily scrums, sprint reviews, and retrospectives. Hinzer also provides tips, hints and things to avoid when implementing Scrum. The presentation aims to help people understand the basics of Agile and Scrum as well as ways to improve their implementation.
This document discusses the challenges and pitfalls of database deployment automation. It notes that databases are often overlooked in development processes and can become weak links. Manual scripting approaches can lead to errors from out-of-process changes and working on the wrong revisions. The document recommends enforcing a coordinated development process using database version control and change management. This allows traceability of changes and ensures deployments are based on known revisions to avoid breaking production environments. Automation is presented as an important part of the solution when integrated with version control baselines and configuration management.
Does this FizzGood? Improve velocity, predictability & agility by asking a si...Jon Terry
Frequent small good decoupled (FSGD) is a way of working that focuses on frequent delivery of small, good changes that are decoupled from each other. This allows for flexibility, learning, and value delivery. Examples show how customizing icons and releasing features can be done in a FSGD way through independent, coordinated changes. The benefits of FSGD include increased marketability, sustainability, frequency of feature delivery, and ability to gain repeat customers through a spirit of continuous improvement.
This document discusses database automation and the mistrust that can exist around it. A survey found that while continuous delivery is on the rise, database automation sees less adoption due to mistrust. Database changes can impact whole systems, so any automation must be done carefully. Script-based version control and deployment can lead to issues like out-of-process changes and working on wrong revisions. Integrating databases into version control and continuous delivery processes through tools like DBmaestro can bring more visibility, control and trust to database changes and deployments. This is done by enforcing best practices, tracking who made changes, and facilitating automated but safe deployments through capabilities like baseline comparisons and impact analysis.
The document discusses the top 10 commonly asked questions in business analyst interviews for agile methodology (Scrum). It defines key Scrum terms and ceremonies like sprint planning, daily scrum, sprint review, and sprint retrospective. It describes the composition of the Scrum team and major Scrum artifacts like the product backlog and sprint backlog. It also explains Velocity, the sprint burndown chart, and the definition of done.
My talk from Drupalcamp London Business Day on 1st March 2013
When building big websites, you're going to face a lot of problems regardless of your technology choice. This talk unveils some of the common problems, and shows how the Drupal community will help you solve these problems.
Slides from the talk "CI doesn’t start with Jenkins" from DevOps Stage 2018 (12-13 October 2018, Kyiv, Ukraine)
CI is not only a tool. You cannot simply install and configure Jenkins or whatever system and say that you have CICD pipeline. Here I'm trying to cover different aspects and dependencies of the CICD process based on Preply Inc experience.
External Links:
[2] CatOps Telegram channel: https://t.me/catops
[2] HashiCorp User Group Kyiv: https://www.meetup.com/Kyiv-HashiCorp-User-Group/
[12-24 ]https://www.endpoint.com/blog/2014/05/02/git-workflows-that-work
[49-50]: https://nvie.com/posts/a-successful-git-branching-model/
[51-56]: https://www.toptal.com/software/trunk-based-development-git-flow
[64] Django Anonymizer: https://github.com/knowledge-point/dj_anonymizer
The document outlines Contactually's new product management framework. Previously, product development was disorganized with work thrown into a large backlog and no clear priorities. The new framework includes: a product vision document, iteration planning spreadsheets, and using Trello and Pivotal Tracker for feature development and engineering tasks. Features are developed in Trello first before being implemented in Pivotal Tracker. The framework provides transparency and ensures stakeholders understand upcoming work and engineers have clear goals. Monthly and sprint meetings keep the team aligned on priorities. The framework has improved productivity by providing structure and accountability.
The document discusses the seven types of waste in software development based on lean manufacturing principles. The seven wastes are: partially done work, extra features, relearning, handoffs, delays, task switching, and defects. It provides examples and explanations of each waste and how agile practices can help manage and reduce waste in software projects.
Agile Scrum is an introduction to agile project management using simple tools. It outlines the key elements, tools, roles, artifacts, and patterns of agile scrum. Simple tools like spreadsheets can be used to manage artifacts like the product backlog, sprint plan, tasks and tracking, burn down charts, and retrospectives. The roles of developers, product owner, and scrum master are described. Artifacts like the product backlog, sprint plan, and tracking sheets are important for recording the inner workings of the agile process. Key agile patterns like iterative planning and tracking help enable the methodology.
Being agile while standing in a waterfallMike Edwards
The document discusses adopting agile practices while still operating within a traditional waterfall development model. It begins with an anecdote about a team that was given a large project with a tight deadline and limited resources that had traditionally used waterfall. The team was able to deliver the project on time and under budget by adopting agile practices like breaking work into smaller projects, establishing team values, and securing executive support. The document advocates that agile principles can be successfully applied even within organizations still reliant on waterfall models.
The document discusses how to prevent agile from becoming fragile. It identifies some common reasons why agile can become fragile such as lack of effective risk management and not extending agile practices to testing and deployment phases. It recommends using risk burn down charts throughout the project lifecycle, adopting automation best practices during testing and deployment, and maintaining interrupts in a separate "ops backlog" to prevent agile from becoming fragile.
Tilt does not currently employ any quality engineers. How can we deliver quality software? Over the last year the organization has gone from terrifying deploys (followed by
Android Developer Skills, Techniques, and Patternsgdgut
Ancestry is a large company that provides family history and DNA testing services. It has over 1 billion records in its databases and over 3 million subscribers. As an Android developer at Ancestry, a typical day involves collaborating with teammates to work on user stories, addressing bugs, learning new skills, and ensuring code quality. Developers focus on testing, code reviews, following best practices, and balancing individual and team work. The goal is to build high quality features while continuously improving skills.
What do making cars and writing software have in common?PayPerks
This document provides an overview of Agile development principles and practices. It discusses how Agile originated as a reaction to waterfall development methods. Key aspects of Agile include iterative development, self-organizing cross-functional teams, and continuous improvement through practices like daily stand-ups and retrospectives. The document also compares Agile software development to Toyota's lean production system, noting similarities like just-in-time delivery and eliminating waste. Finally, it provides details on how a company called PayPerks has implemented Agile practices in their development process.
Practical Methods for Adopting DevOps - Michael StahnkePuppet
The document outlines 5 methods for adopting DevOps practices in large organizations with siloed IT teams: 1) Standardize variable infrastructure to reduce failures, 2) Break down silos through collaboration between teams, 3) Share knowledge of failures to prevent recurrences, 4) Experiment with new tools and processes in test environments, 5) Continuously improve processes by addressing root causes rather than symptoms. The methods advocate reducing variability, integrating operations into software development, conducting root cause analyses, and allowing engineers to experiment.
Similar to A Filter Junkie's Guide to Increasing Productivity and Visibility - Atlassian Summit 2012 (20)
We aim to celebrate women every day, but we’re taking today to give special recognition to womxn at Atlassian continue who inspire and lead.
For #InternationalWomensDay, we asked Atlassians to nominate and recognize amazing womxn at Atlassian who inspire them, challenge them, and truly represent Atlassian values.
Ever wondered what Atlassian engineers do in their 20% time? Join Forge engineering lead Tim Pettersen on a lightning tour of how Forge is being used inside Atlassian. Attendees will get a rare view into some of the apps, tools, and tweaks we’ve built internally on top of Forge in the spirit of dogfooding and innovation. Come along and be inspired with some great ideas for improving and automating your own teams' workflows!
Let's Build an Editor Macro with Forge UIAtlassian
Race out of the gate with Forge UI: a new way of building UI extensions for Atlassian products. In this session, Forge UI Developer Experience lead Peter Gleeson will demonstrate how build an Editor macro from scratch! Attendees will learn about Forge foundational concepts such as the FaaS dev loop, Forge CLI, and how to construct UIs from Forge UI components.
This session provides a great introduction to the Forge platform for any developer looking to get productive with editor apps and Forge UI.
In the words of Jeff Atwood: “JavaScript is the lingua franca of the web”. It’s also the first language we’ve chosen to support in Forge. In this session, Forge engineer Shorya Raj will walk through the Node.js isolate based runtime you’ll be using to write apps for Forge.
Attendees will learn about the unique features of the Forge JavaScript Runtime, such as automatic authentication and tenant context management. Shorya will also cover the differences between the Runtime, conventional browser, and Node.js APIs.
Developers or attendees with some programming experience will get the most out of this session.
Forge UI: A New Way to Customize the Atlassian User ExperienceAtlassian
UI extensibility is an integral part of Atlassian's ecosystem story. In cloud, traditionally this has been accomplished with the humble iframe. In this session you will learn about Forge UI, an additional and innovative way to build visual apps for Atlassian products.
Join Product Manager Simon Kubica and Senior Developer Michael Oates from the Forge team in exploring the underlying concepts and technology powering Forge UI, and learn how it will unlock exciting new opportunities in our ecosystem.
This document discusses using triggers to automate actions in Forge apps. It begins with an overview of triggers and then discusses:
- Product triggers that are triggered by events in Atlassian products like Jira, Confluence etc.
- Web triggers that are triggered by HTTP requests to a Forge function.
- How to authenticate and make requests to external services like Opsgenie from Forge functions in response to triggers.
- Demos of building a Forge app that responds to Jira issue creation by assigning the issue and notifying Opsgenie.
The document provides details on the event payload formats, making authenticated requests, and deploying/managing the Forge app lif
Observability and Troubleshooting in ForgeAtlassian
The document discusses the evolution of software development from bare metal servers to virtualization, containers, and serverless functions. It notes how debugging and observability have become more difficult as software moves to remote "somebody else's computer" environments. The author introduces Forge as Atlassian's solution for providing developers a declarative language and best-in-class experience for building user interfaces on serverless infrastructure, including features for debugging, monitoring, and security.
Trusted by Default: The Forge Security & Privacy ModelAtlassian
Security and trust have become increasingly important requirements for our customers in Cloud. We’re working to make it easier for you to build and maintain secure apps for Atlassian products.
In this session, Engineering Team Lead Dugald Morrow and Principal Product Manager Joël Kalmanowicz will explain how security and trust have been baked into the Forge framework and the benefits the platform can offer you and your users. Learn how much less work it can be to build trusted apps customers will love on Forge by going deep on the safeguards we’re putting in place.
Developers or attendees with some software security experience will get the most out of this session.
Designing Forge UI: A Story of Designing an App UI SystemAtlassian
Creating apps with Forge and its UI frontend components is now easier than ever. Join Senior Designer Allard van Helbergen and Product Manager Josephine Lee as they walk through the story of designing Forge UI.
What is a declarative UI and why did we choose this paradigm? What are all the considerations that go into defining the set of components to build apps with? And how do you make ‘creating apps’ simple? Walk away understanding the foundations of Forge, how all the different components work together, and where Forge UI is headed in the future.
After a day of learning about the exciting features of Forge, get ready for a peek under the hood to discover how it’s all implemented. Join Forge Architect Patrick Streule as he goes deep on topics such as Forge FaaS infrastructure, the internal workings of tenant isolation, and automatic authentication.
Attendees will also get a glimpse of some features we’re looking at building into the future of Forge, such as a serverless data store for apps and more!
Access to User Activities - Activity Platform APIsAtlassian
How do you stay on top of your work when it is scattered across multiple Atlassian products?
"If only there was a single place where I could see all my activity..." - sounds familiar?
We are going to provide you an insight into what lead to the creation of a new Activity API. Following last year’s Atlas Camp announcement from our CTO Sri Viswanath, Atlassian is moving onto GraphQL - new Activity API is one the first pieces of the GraphQL Atlassian Platform and is the technology behind start.atlassian.com.
Join Sergey Meshkov, Senior Developer, who will provide you a sneak peek of the new GraphQL Activity API as it will soon be available to our vendors.
Design Your Next App with the Atlassian Vendor Sketch PluginAtlassian
Our designers work 3x quicker with the Atlassian Vendor Sketch Plugin — and now we’re unleashing these superpowers to the Atlassian Ecosystem. If you mockup screens for code or marketing, we’ll help you drag and drop your way to an Atlaskit design in less than 10 minutes. And if you’re a designer, you’ll want to hear about our pixel-perfect component library and suite of seamless Sketch integrations.
Join Atlassian’s resident Sketch aficionado, Huw Evans, to learn about:
Sketch Components: If it’s in Atlaskit, it’s now in Sketch. And introducing the Symbol Palette, the quickest way to find the right component for the job.
Product Templates: Spark inspiration by building your designs inside realistic screens from Jira & Confluence — or craft hero images for your Marketplace listing!
Color and Text Styles: Heard of N75? H400? If those mean nothing to you, we’ll run through how to make your users feel at home by using Atlassian colors & typography, right inside Sketch.
Data Suppliers: Say goodbye to Lorem Ipsum. Learn how to use Sketch Data Suppliers to generate realistic copy using live data from Jira, Confluence and Bitbucket. Bonus: How we used AI to create people who don’t exist!
♀️ It's All Open Source: How we made it really easy to customise the Atlassian Vendor Sketch Plugin for your team's needs.
Tear Up Your Roadmap and Get Out of the BuildingAtlassian
The document discusses conducting customer research by tearing up existing roadmaps and getting out of the building. It recommends running a research spike with the team to define what needs to be learned. Tips are provided for recruiting participants through support, community, and sales teams. Conducting customer interviews is discussed, including roles for scribes and interviewers. Analyzing interviews by consolidating themes from transcripts is also covered. An example analysis identified themes around customer journeys, collaboration as a team sport, and overwhelming demand for participation. The document encourages being honest about whether a research spike could be run and why or why not.
Nailing Measurement: a Framework for Measuring Metrics that MatterAtlassian
When it comes to designing apps and new features, we just can't get enough of metrics. In an age where we can collect data from almost anything, how can we cut through the noise and focus on the right metrics to measure the success and failures of the apps that we’re building?
Join Atlassian Product Manager Josephine Lee as she delves through what exactly makes a good metric. Throughout the talk, we’ll walk through real Atlassian examples of good and bad metrics. By exploring a framework for measurement, we’ll cover detailed features that showcase how best to measure and choose the right set of success, supportive, and counter metrics.
You'll walk away with tips and learnings from Atlassian’s approach to measuring success, and learn how to use data and metrics to inspire action in your apps.
Building Apps With Color Blind Users in MindAtlassian
Color-blind people are using your apps. 1 in 12 men is color blind. And for women, this is 1 in 200.
Building apps that work well for color blind people is not difficult. Some simple techniques help us with the design of our interface. And some tools help us see what color blind people see.
In this talk, Maarten Arts of Avisi will look at common varieties of color blindness. We will look at apps through the eyes of a color-blind person. And we will discover what color-blind people struggle with.
Regardless of whether you're a designer or developer, this talk will equip you with the skills and the tools you need to make sure that your app works for color-blind people.
Creating Inclusive Experiences: Balancing Personality and Accessibility in UX...Atlassian
The words we choose have the power to include or alienate our users. The reality is that for many, English is spoken as a second language. And unless you're going to localize your product for those major non-English speaking markets, you'll need to thoughtfully create content that is accessible to a larger audience.
But how do we create products that maintain a sense of personality without isolating a wide audience of non-native speakers?
Join Atlassian Content Designer, Roana Bilia, as she walks you through why thoughtful, inclusive content, is key to creating well-designed user experiences. You'll walk away with foundational principles for good UX copy when optimizing your product UI, a few quick wins that you as creators and developers can incorporate into your next products, as well as a set of mistakes to avoid that companies—including Atlassian—have made, which prioritized native speakers but isolated non-native speakers.
Beyond Diversity: A Guide to Building Balanced TeamsAtlassian
We hear it all the time, and we get it. Diversity and inclusion are important! But isn't it an HR problem? HR may be able to help with diversity but inclusion or creating an inclusive environment is everyone's responsibility. So how do we create an inclusive environment that celebrates diversity and engages and supports everyone? Isabel Nyo will be sharing best practices and lessons she has learned along the way. She will also be sharing her experience as a minority, a female technical leader, in the technology industry.
The Road(map) to Las Vegas - The Story of an Emerging Self-Managed TeamAtlassian
In September 2018, K15t took its mission to go self-managed to the next-level when the entire company worked together to decide on the Next Big Thing™ to build for Atlassian users and present it at Summit in Las Vegas.
In this session, Anshuman Dash, an intern turned software engineer, turned product manager, shares his journey of professional self-discovery. In under five months, he joins a freshly assembled, self-managed team in building a new Atlassian Marketplace app.
Dash will give a quick intro to what it means for a team to be self-managed. Then, he'll share his observations and experiences on the team, as well as the best-practices, patterns, and processes K15t has discovered along the way.
Whether you are a new team with a kick-ass product idea or a big company figuring out ways to scale, this talk will provide you with practical tips and ideas your team can try out!
Designing for the enterprise comes with a unique set of challenges; ensuring readability and accessibility at scale, meeting the needs of multi-layered organizations, and building a trust when your software - used by dozens of thousands of employees - is considered mission-critical.
At Atlassian, we've spent countless hours digging deep into our enterprise customer's needs and we've gathered a vast repository of insights.
In this talk, Pawel Wodkowski, a senior designer on Jira Server, will share all that we've learned from our research (while not being shy about busting some of those wild admin myths!). You'll get a crash course in what it means to design for scale the Atlassian way.
Turkey vs Georgia Tickets: Turkey's Redemption Quest in Euro 2024, A PreviewEticketing.co
Euro Cup Germany fans worldwide can book Euro 2024 Tickets from our online platform www.eticketing.co.Fans can book Euro Cup 2024 Tickets on our website at discounted prices.
❽❽❻❼❼❻❻❸❾❻ Matka BOSS Result | Satta Matka Tips | Kalyan Matka 143dpbossdpboss69
Satta BOSS Matka | DpBoss Matka | Matka BOSS Result | Satta Matka Tips | Kalyan Matka 143 · SATTA KING · ➥ SATTA MATKA TIME TEBAL · SATTA KING · ➥ Weekly ...
Euro Cup fans worldwide can book Euro 2024 Tickets from our online platform www.worldwideticketsandhospitality. Fans can book Mexico FIFA World Cup Tickets on our website at discounted prices.
Albania vs Spain Albania's Last Stand Must-Win Clash against Spain in Euro 20...Eticketing.co
Euro 2024 fans worldwide can book Albania vs Spain Tickets from our online platform www.eticketing.co Fans can book Euro Cup Germany Tickets on our website at discounted prices.
Serbia vs England Tickets: Serbia's Euro Cup Germany Journey and England's An...Eticketing.co
Eticketing.co offers UEFA Euro 2024 Tickets to admirers who can get Serbia vs England Tickets through our trusted online ticketing marketplace. Eticketing.co is the most reliable source for booking Euro Cup Final Tickets. Sign up for the latest Euro Cup Germany Ticket alert.
Euro Cup 2024 Preview, Prediction, Kick-Off Time Team News for Germany vs Swi...Eticketing.co
Hordes Germany will look to triumph on home soil at Euro Cup 2024 this seasonal. The three-time Euro Cup Germany champions have disappointed at recent major tournaments, exiting the last two World Cups in the group epochs and only reaching last-16 of Euro 2020, where they lost to England at Wembley three years before.
We offer Euro Cup Tickets to admirers who can get Switzerland vs Germany Tickets through our trusted online ticketing marketplace. Eticketing.co is the most reliable source for booking Euro Cup Final Tickets. Sign up for the latest Euro Cup Germany Ticket alert.
uro Cup 2024 Tickets | Euro Cup Tickets | Euro Cup Final Tickets | Georgia Euro Cup Tickets
But Julian Nagelsmann will be out to recuperate the spirits of the home nation and recent victories over France and the Netherlands in friendly contests was a sign that Germany will be among the competitors for the title this summer.
Scotland, Switzerland and Hungary delay in Group A, with Germany kicking off the UEFA Euro 2024 against the Scots in Munich on June 13. Nagelsmann’s crew has been bolstered by Bayer Leverkusen’s remarkable unbeaten Bundesliga accomplishment, with star Florian Wirtz named player of the year in the German top-flight.
The 21-year-old star adds to a quantity of national team stalwarts who remain from Germany’s World Cup triumph in 2014, with Thomas Muller and Manuel Neuer amalgamated by the returning Toni Kroos, who is back from international withdrawal.
Euro Cup 2024: Julian Nagelsmann Announces Euro Cup Germany's 27-Player Preliminary Squad
Julian Nagelsmann named a 27-player introductory Euro Cup squad on 16 May. This must be cut down to at least 26 players, including three goalkeepers, by the 6 June target.
Goalkeepers: Manuel Neuer (Bayern Munich), Marc-Andre ter Stegen (Barcelona), Oliver Baumann (Hoffenheim), Alex Nubel (Stuttgart),
Defenders: Waldemar Anton (Stuttgart), David Raum (RB Leipzig), Antonio Rudiger (Real Madrid). Moreover Nico Schlotterbeck (Borussia Dortmund), Jonathan Tah (Bayer Leverkusen). Benjamin Henrichs (RB Leipzig), Joshua Kimmich (Bayern Munich), Robin Koch (Eintracht Frankfurt), Maximilian Mittelstadt (Stuttgart)
uro Cup 2024 Tickets | Euro Cup Tickets | Euro Cup Final Tickets | Georgia Euro Cup Tickets
Midfielders: Toni Kroos (Real Madrid), Jamal Musiala (Bayern Munich), Aleksandar Pavlovic. Although, Robert Andrich (Bayer Leverkusen), Chris Fuhrich (Stuttgart), Pascal Gross (Brighton and Hove Albion). Florian Wirtz (Bayer Leverkusen), Ilkay Gundogan (Barcelona), (Bayern Munich), Leroy Sane (Bayern Munich)
Forwards: Thomas Muller (Bayern Munich), Deniz Undav (Stuttgart), Maximilian Beier (Hoffenheim), Niclas Fullkrug (Borussia Dortmund), Kai Havertz (Arsenal)
Switzerland vs Germany: Murat Yakin Announces Switzerland Euro Cup 2024 Preliminary 38-Man Squad
Executive Murat Yakin selected a preliminary 38-man Euro Cup 2024 squad on May 17. Due to a number of his troupes still active on club duty. "As many experienced
Euro 2024 Key Tactics and Strategies of the Netherlands.docxEticketing.co
We offer Euro Cup Tickets to admirers who can get Netherlands vs Austria Tickets through our trusted online ticketing marketplace. Eticketing.co is the most reliable source for booking Euro Cup Final Tickets. Sign up for the latest Euro Cup Germany Ticket alert.
Serbia vs England Tickets: Serbia Gears Up for a Historic Campaign at UEFA Eu...Eticketing.co
Eticketing.co offers UEFA Euro 2024 Tickets to admirers who can get Serbia vs England Tickets through our trusted online ticketing marketplace. Eticketing.co is the most reliable source for booking Euro Cup Final Tickets. Sign up for the latest Euro Cup Germany Ticket alert.
This presentation is version 3 of the strategic plan for Real Bedford Football Club.
Our goals are:
1. Men's Team - To bring League Football to Bedford and ultimately get us into the Premier League.
2. Women's' Team - To bring Championship to Bedford and ultimately get us into the Women's Super League.
Kylian Mbappe Misses Euro 2024 Training Due to Sickness Bug.docxEuro Cup 2024 Tickets
France is among the top contenders to win Euro Cup 2024 and will rely on star forward and captain Kylian Mbappe to lead Didier Deschamps' team to success in Germany
Serbia vs England Tickets: Serbia's Historic Euro 2024 Journey, A Blend of Ex...Eticketing.co
Eticketing.co offers UEFA Euro 2024 Tickets to admirers who can get Serbia vs England Tickets through our trusted online ticketing marketplace. Eticketing.co is the most reliable source for booking Euro Cup Final Tickets. Sign up for the latest Euro Cup Germany Ticket alert.
Belgium vs Romania A Comprehensive Preview of Euro 2024 Campaigns, Key Player...Eticketing.co
Euro 2024 fans worldwide can book Belgium vs Romania Tickets from our online platform www.eticketing.co. Fans can book Euro Cup Germany Tickets on our website at discounted prices.
Indian Premier League (IPL) ---2024.pptxrathinikunj60
The Indian Premier League (IPL) is one of the most prominent and lucrative Twenty20 (T20) cricket leagues in the world. Since its inception in 2008, the IPL has revolutionized the landscape of cricket by blending sports, entertainment, and commerce. This summary provides an overview of the IPL's history, structure, notable performances, controversies, and its impact on cricket and beyond.
History and Formation
The IPL was launched by the Board of Control for Cricket in India (BCCI) in 2008, inspired by the success of domestic T20 leagues like the English T20 Cup and the now-defunct Indian Cricket League (ICL). Lalit Modi, the then Vice-President of BCCI, played a crucial role in conceptualizing and launching the league. The inaugural season kicked off in April 2008 with eight franchises representing different cities in India.
Structure and Format
The IPL follows a franchise-based model, where teams are owned by a mix of corporations, Bollywood stars, and other high-profile individuals. The league originally started with eight teams, although the number has fluctuated over the years due to various reasons including expansions and terminations. As of the latest seasons, the IPL features ten teams.
The tournament format includes a double round-robin stage, where each team plays the others twice, followed by playoffs. The top four teams from the round-robin stage qualify for the playoffs, which consist of two qualifiers, an eliminator, and the final. This format ensures a highly competitive and engaging tournament, culminating in a grand finale to crown the champion.
Teams and Their Evolution
The founding teams of the IPL were:
Chennai Super Kings (CSK)
Delhi Daredevils (now Delhi Capitals)
Kings XI Punjab (now Punjab Kings)
Kolkata Knight Riders (KKR)
Mumbai Indians (MI)
Rajasthan Royals (RR)
Royal Challengers Bangalore (RCB)
Deccan Chargers (now defunct, replaced by Sunrisers Hyderabad)
Over the years, the league has seen new teams such as Pune Warriors India, Kochi Tuskers Kerala, Gujarat Lions, and Rising Pune Supergiant. The most recent additions are the Gujarat Titans and Lucknow Super Giants, introduced in the 2022 season.
Iconic Players and Performances
The IPL has attracted the best talent from around the world, with numerous iconic players making significant contributions. Some of the standout performers include:
Sachin Tendulkar (MI): The "Little Master" brought his legendary status to the IPL, winning the Orange Cap (top run-scorer) in 2010.
Chris Gayle (RCB, KXIP): Known for his explosive batting, Gayle holds the record for the highest individual score in an IPL match (175*).
MS Dhoni (CSK): Dhoni's leadership has been instrumental in CSK's success, leading them to multiple titles.
AB de Villiers (RCB): Renowned for his innovative stroke play, de Villiers has been a consistent match-winner.
Virat Kohli (RCB): The highest run-scorer in IPL history, Kohli's batting prowess is unmatched.
La
Playing this fast-paced game, you control a small cube that has to get through stages that get harder by avoiding spikes, obstacles, and dangerous gaps while keeping up a fast pace. Though, it's important to remember that Geometry Dash isn't a simple game to get good at. No matter what mistake you make, you will face a tough position and have to start at the beginning.
The sounds and sights in Geometry Dash are very interesting. Your attention will be drawn to the simple style and catchy melodies. While the game looks good, it's not just visually challenging; getting through the tricky rounds requires quick thinking and reflexes.
The stages get harder over time, testing your skills and forcing you to find new ways to get past problems that other people have found impossible. Your experience with Geometry Dash will be remembered for a long time because of how satisfying it is to beat a difficult level or find a secret route. Join the many people who love Geometry Dash and are fascinated by this exciting and fun game. Get ready, because things will move quickly!
27. Team Dashboards
• At a glance sprint health
• Important information
• Impediments
• Burndown
• Defects
• Work In Progress (WIP)
28. Your turn!
• Additional materials at:
JIRAjunkie.blogspot.com
• Step-by-steps
• JQL for all of the filters
presented
• Some additional tips & tricks
29. Your turn!
• Additional materials at:
JIRAjunkie.blogspot.com
• Step-by-steps
• JQL for all of the filters
presented
• Some additional tips & tricks
Hi, my name is Reese Gibbons. I work at uShip as a ScrumMaster. I’ve been using JIRA for about 6 years now, and I have become completely addicted to Filters & Dashboards. Of 180 filters in our JIRA instance, over 100 are mine as well as half of the public Dashboards. \n\nI think I might actually have a problem. Let’s see if I can show you guys how I use my strange obsession to keep myself, my Scrum Teams and Product Owners in loop on any issues and focused on the current sprint. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Let me give you a bit of the back story. We have been a JIRA shop since 2007. We have been transitioning our process to a more agile framework for the better part of three years, and we officially moved to Scrum last September. \n\nThese are my teams. Yes, there are six. I’m aware that this sounds completely insane, but this is the situation, and I am more than embracing it. What this means, though, is that I don’t have a ton of time to gather information on the health of a team or their sprint. I have 6 scrums back to back every morning, with, if I’m lucky, a minute in between to see if we have any pain points. This meant clicking through numerous pages to see how many defects we had open, how the sprint is going, if there are any impediments, and so on. It was time to create dashboards. \n
Even if you aren’t in a similar situation trying to track multiple teams, projects or products, setting up a good dashboard to pull your daily relevant information to an at a glance medium will be super useful and can save you a ton of time. \n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
So what makes a good dashboard? First, figure out what you need it for? An aimless dashboard will become junked up very quickly, and you won’t be able to deduce what’s important. \n\nYou want your dashboards to be as easily digestible as possible. Put the most important information right at the top and let everything filter down from there.\n\nLimit your information! Information overload will kill your dashboard. Don’t pull every bit of data you can think to pull. Filters that you don’t need to see everyday don’t necessarily need to live on your dashboards. Gadgets that don’t add direct value to the purpose don’t make the cut.\n\nIf you find that you are overloading the dashboard or can’t figure out what gadgets should live above the fold, you may be trying to use one dashboard for multiple purposes. Make another one. Split the information. You will be doing yourself a huge favor. As you can see I have about 15, and yes, I look at them everyday.\n
Let’s go through one of my teams’ dashboard to show you how where I was going in this process and how to get the most out of some really great gadgets\nThe purpose of the team dashboard is to provide full visibility for the team and product owner into the health of the sprint.\nThe most important pieces of information that we need to see are Impediments, Sprint Burndown, Defects, and a gadget to highlight our cumulative Work In Progress.\nI realize you guys can’t see the details on these so I’ve broken this down a bit further.\n
I wanted to make sure Impediments were given a prominent spot on the dashboard. Impediments derail my teams’ progress, and the whole team as well as the P.O. should be aware of them. I set up a filter to pull anything that was flagged as an impediment on this team, and added the “filter results” gadget to display those here. \n\nWhen you add this gadget you can choose which fields to show based on your particular needs or go with the default. Feel it out to see what works best for you.\n
I wanted to make sure Impediments were given a prominent spot on the dashboard. Impediments derail my teams’ progress, and the whole team as well as the P.O. should be aware of them. I set up a filter to pull anything that was flagged as an impediment on this team, and added the “filter results” gadget to display those here. \n\nWhen you add this gadget you can choose which fields to show based on your particular needs or go with the default. Feel it out to see what works best for you.\n
Greenhopper has a fantastic chart setup to automatically track sprint burndowns, and a built in Agile Gadget so that you can add it to your dashboards to display it. This gadget can also track a ton of other usefulness and will link you to the issue tracker, taskboard, planning board, and a few other places. But since we are looking for a quick “at-a-glance” view, I keep it set to the Burndown. \n\nWe have this set to Story Points, but you can set it to just about any statistic you want to track. A quick overview: The Red line is our guideline. The green is our burndown. And the orange line shows how many points we would need to close out daily to meet our commitment.\n
Just a heads up there are a few quick steps to set it up that I was completely unaware of for months. I was creating burndowns in excel, because I just couldn’t make it work. \n
First, you have to Add the new sprint from the Planning board\n\nSecond, and this is the key, you must enter a Start Date and End Date. If you don’t your burndown will only track 2 days \n\nBack to our dashboards.\n
First, you have to Add the new sprint from the Planning board\n\nSecond, and this is the key, you must enter a Start Date and End Date. If you don’t your burndown will only track 2 days \n\nBack to our dashboards.\n
First, you have to Add the new sprint from the Planning board\n\nSecond, and this is the key, you must enter a Start Date and End Date. If you don’t your burndown will only track 2 days \n\nBack to our dashboards.\n
First, you have to Add the new sprint from the Planning board\n\nSecond, and this is the key, you must enter a Start Date and End Date. If you don’t your burndown will only track 2 days \n\nBack to our dashboards.\n
First, you have to Add the new sprint from the Planning board\n\nSecond, and this is the key, you must enter a Start Date and End Date. If you don’t your burndown will only track 2 days \n\nBack to our dashboards.\n
First, you have to Add the new sprint from the Planning board\n\nSecond, and this is the key, you must enter a Start Date and End Date. If you don’t your burndown will only track 2 days \n\nBack to our dashboards.\n
Tracking defects can really give you a feel of the health of your process. I keep a “Created vs Resolved” Chart of defects looking back 14 days. This chart is a gadget that comes with JIRA that you can set to look at any of your favorite filters. If the red goes above the green (meaning we are creating more defects than we are closing out) that may be an indication that we are over-commiting and possibly cutting corners or testing to meet sprint goals. You can see this team knocked out a ton of defects, while not really creating many. \n\nBut this one, while being in the red, is doing a pretty great job of resolving the defects as they come in. We have a Zero Known defects policy, so this is bueno.\n
Tracking defects can really give you a feel of the health of your process. I keep a “Created vs Resolved” Chart of defects looking back 14 days. This chart is a gadget that comes with JIRA that you can set to look at any of your favorite filters. If the red goes above the green (meaning we are creating more defects than we are closing out) that may be an indication that we are over-commiting and possibly cutting corners or testing to meet sprint goals. You can see this team knocked out a ton of defects, while not really creating many. \n\nBut this one, while being in the red, is doing a pretty great job of resolving the defects as they come in. We have a Zero Known defects policy, so this is bueno.\n
I also included a Filter Results gadget of open defects for this team. It’s not only important to see the rate at which we are producing defects, we also need to know exactly what is out there. \n
On this team we are really working on Minimizing Work In Progress and getting things across the finish line one at a time. So I set up this to really give them an idea of how they were doing at this goal. This is the Cumulative Flow Chart, another awesome Greenhopper Gadget. It gives me a great feel of our pacing by tracking the tickets in the sprint by status. If we are knocking out Stories one at a time, this should have a nice up and to the right flow. It looks pretty good this sprint.\nThere are two things that I want to point out. See the orange and purple swaths? These are the “In Dev” and “In QA” flows. As long as these stay relatively thin, we are doing a good job of minimizing WIP. \n\nThe second thing that I absolutely love about this chart (and that makes my P.O.s and Devs think I’m super sneaky)? It takes a snapshot each day. I knows the number of tickets in or out. See how the top edge climbs as the sprint goes on. This means tickets have been pulled in. In this case it was all those defects that they were fixing. The line just about follows the same pattern. But check this out. Check out their original commitment vs what they actually got done. Sneaky sneaky. \n\nAs one of my jobs is protecting the team from changes to their sprint commitment, this is great information to have. \n
These are the 5 things that make up the team dashboards. As the teams are focusing on different goals or require different bits of information, I will swap out gadgets and filters to make sure they get the most out of their dashboard. Each member of the team or the P.O. should be able to open this up and get a quick feel for the health of the sprint.\n
Now it&#x2019;s your turn. Go create a dashboard of your own. Save yourself some steps. Create a ton of visibility at all levels. JIRA is an information powerhouse! Every field is searchable in some form or fashion and you have all of the tools at your disposal to make it yours!\n\nAlso, I&#x2019;ve added step-by-steps and the JQL for all of the filters I presented to <website>. Thanks for your time. Enjoy the rest of the summit.\n\n \n
Now it&#x2019;s your turn. Go create a dashboard of your own. Save yourself some steps. Create a ton of visibility at all levels. JIRA is an information powerhouse! Every field is searchable in some form or fashion and you have all of the tools at your disposal to make it yours!\n\nAlso, I&#x2019;ve added step-by-steps and the JQL for all of the filters I presented to <website>. Thanks for your time. Enjoy the rest of the summit.\n\n \n