Good reporting capabilities are essential to Agile teams using Jira Software - and for good reason! Data visualization tools are essential for promoting good communication and collaboration. One of the most sought-after reports is included in Jira Software out of the box: the burndown chart. Read on to learn how Jira makes it easy to generate and share the burndown chart with your team and stakeholders. 

The Inputs

1. A Scrum Board: In Jira, the burndown chart is accessible through Scrum boards only.
   • To create a scrum-type board, follow these instructions from Atlassian. Column mapping is a key configuration point, as it's the basis for the burndown chart. 
2. An Estimation Statistic: Determine how your team will measure work, and set an estimation value on each of the issues in your sprint.
   • Jira accommodates for Story Points, original time estimate, issue count, or any custom field, provided that the custom field is a numeric custom field type.
   • We know that this can be a sticking point for your team and asked our Principle Amanda Babb to shared her thoughts about Scrum Team time tracking to help you along the way. 
3. An Active Sprint: Once your sprint starts, begin to review your team's progress. 

The Interpretation

Once the sprint starts, you can review the burndown chart along the way to understand the amount of remaining work in a particular sprint and gather feedback on the sprint itself. Below are a few scenarios that the burndown chart captures:

Scope Creep:

Scope creep is often unavoidable, so it's necessary to understand when they occurred especially if you team is no longer on target to meet its sprint goal. Here, the burndown chart reflects an increase in scope

Opportunity for Alignment: 

It's important for the team to collaborate and land on an estimate for each work item in the sprint - not so much for the actual estimate itself but more for the shared understanding based on the requirements. This is often seen in both over and under estimates on the burndown chart. Below, the burndown chart reflects where some work was overestimated; the team is on track to the work well before the end of the sprint. 

Plateaus: 

Plateaus on the burndown chart are typical when you have a team who is either new to Agile as a whole or new to working together. It's an indication that the team got off to a good start early on, but didn't carry the effort through the remaining work items. 

Ready to learn how Jira Software can help your Agile teams collaborate and communicate while working in Agile sprints? Drop us a line!

With Atlassian's upcoming release of Jira Data Lake for Jira Software Cloud, it's a good time to review the jargon we might stumble on in the reporting and business intelligence (BI) space. So let's jump into the (data) lake!

One word of caution: the BI industry has many players with varied opinions. Some terms get used and reused in multiple ways. One example is the emerging use of "lakehouse" - a combination of "data lake" and "data warehouse." Here we'll stick to as close to canonical as possible but expect to see terms used differently as you research.

Why does BI even matter? What are KPIs?

Your organization has systems (e.g. computer applications) which create and contain data. That data is extremely valuable for fact-based decision making in your organization. 

A CTO or CIO is able to more effectively allocate help desk head count with ready access to accurate metrics (also called Key Performance Indicators, or KPIs) like Mean Time To Acknowledge (MTTA) and Mean Time To Resolve (MTTR). (Note: MTTR is a tricky acronym. As Atlassian notes, there are at least four common incident management metrics that share this abbreviation! This stuff can be confusing...)

To provide these valuable, up-to-date KPIs to decision makers, we turn to BI. This industry is a dizzying array of technology components which take various approaches to achieving BI's primary objective: turning raw data into actionable insight. Often, we need to integrate multiple BI components to get from point A (data in the source system) to point B (reports used for decision making).

BI solutions often leverage a data lake or data warehouse to store business data.

What is a data lake?

A data lake is a central store of raw business data. The data lake is not typically used by the source systems whose data it contains.

The lake is designed to be accessed by tools like Tableau, PowerBI, and Qlik in order to analyze and produce insights from the data. We'll call these analysis and presentation applications "BI tools." To continue the lake analogy: if the BI tool is a fishing rod, then the data is the fish.

A data lake typically uses a file store technology but when it comes to Jira Data Lake, we don't really need to know much about the underlying tech because Atlassian Cloud takes care of choosing, configuring, hosting, and maintaining it for us. One less thing on our plate? Great!

All we need to do is connect our BI analysis and presentation tools (Tableau, PowerBI, Qlik, etc.) to Jira Data Lake. Boom! We're ready to start creating reports, graphs, dashboards, and whatever else we need to answer questions for our organization.

How is a lake different from data warehousing?

As mentioned earlier, some BI solutions use a data warehouse instead of a data lake. Some use both. While the line has blurred between the two, lakes are usually more unstructured than warehouses.

The initial data lake concept encouraged organizations to dump all of their raw data into the lake, including data from relational databases, flat files (e.g. CSV files), videos, and more. The promise that smart software and ever-increasing computing horsepower would eventually create solutions for accessing the overwhelming amount of data in the lake hasn't really come to fruition quickly enough. And many data lakes turned into data swamps. Lakes these days, like Jira Data Lake, are more purpose-built and have better designs for preventing a descent into swampland.

A data warehouse is more structured and normally designed with transformation processes on the front- and/or back-end that clean, normalize, and handle any other standardization before presenting it to our BI tools. These processes are represented by the "T" (Transform) in some more acronyms: ETL (Extract Transform Load) or ELT. The result is more predictable and accurate, but the cost and time to create these transformation processes is much higher.

Why use a data lake?

Why invest in this effort to centralize data in lakes or warehouses? Our BI tools can often connect directly to our application's database. Wouldn't it be easier to skip the lake/warehouse?

Eliminating the data lake or warehouse would simplify our solution design but experience has shown multiple issues with the direct-connect approach.

The most critical issue is often the potential load a BI tool can place on an application database. BI queries often require large swaths of data which can only be fulfilled through heavy workloads on the database. In addition, BI tools often don't optimize queries for performance. BI workloads can cause database contention and application stability should always be prioritized over BI needs. With today's easy-to-use BI tools accessible to a larger and less technical audience, this issue has only become more prevalent. Connecting our BI tools to a data lake prevents risking any application stability issues.

The next most common issue we see is needing to combine data from multiple systems. Since your organization doesn't just use one system, combining data across the organization is how so many powerful insights occur. For example, tying Jira KPIs to financial data is one way leaders can more easily understand technical metrics. But financial data is stored in the accounting system, not Jira. A direct connection to an application's databases only allows access to that system's data, preventing cross-system data analysis. While some BI tools allow you to perform "cross-database joins," performance is often unacceptable and some links are just not possible. Often the data from different systems needs to be cleaned and standardized before it can be linked for analysis. Doing this in a data lake/warehouse is far more efficient than attempting it "at runtime" in BI tools. When we first centralize our data we have the ability to combine data from as many systems as needed.

BI is all about trends over time. Some applications don't maintain much, if any, historical data. A direct connection to these systems doesn't allow for time-based analysis. The historical data simply doesn't exist. Lakes allow us to snapshot data at regular intervals in order to perform valuable time-based analysis.

Finally, with cloud apps like Jira Cloud, we don't have the option to connect directly to the application database. The only data access is often through APIs which can be slow for analysis and suffer from many of the same issues mentioned above. Jira Data Lake provides performant, safe data access.

Data lakes arose from the need for flexibility. No two organizations use the same systems or have the same data needs. Your organization's data needs will also change over time. The direct connection to an application database is too tightly coupled and doesn't provide enough agility to provide BI insights.

If you're wondering if this powerful new tool is a good fit for your organization, or have any questions about anything Atlassian, contact us, one of our experts would love to help!

One of the most important metrics for IT and Customer Service teams that solve problems and answer customer questions is mean time to resolution, commonly referred to as MTTR. Atlassian defines MTTR as the average time it takes for an issue to reach a resolved state, as measured from the time the ticket was created. It’s an exceedingly important metric to track, especially for IT teams because it is one of the few great ways to quantify team productivity. When tracked and reported over time, it becomes possible to determine the efficacy and ROI of business process improvements. While Jira gives us an easy way to track service level agreements (aka SLAs), there is no great built-in tool for tracking MTTR (yet).

Fortunately, as with most desired features in the Atlassian ecosystem, there’s an app for that. We’ve discussed eazyBI quite a bit in the past, and for good reason: it is simply one of the best data aggregation and reporting tools available for Jira. Period.

To track MTTR, try using the Issue Resolution Days report. This report can roll up all of your issues and report average MTTR, broken down by issue type and time period. As with most eazyBI reports, you can customize this one just about any way, including which additional metrics to report on (such as median, min, and max time to resolution) and total or average hours logged. You can even set up your data visualization exactly how you want it.

If you’d like to learn more about the Issue Resolution Days report, eazyBI has some excellent documentation. 

One important thing to keep in mind when a team begins tracking MTTR is to make sure you properly define when an issue is resolved in your Jira instance. Without this clear definition, you may have trouble collecting data, or worse, you report on the wrong information. Tracking your MTTR to learn more about how you can reduce this metric can help your organization save time and resources, as well as contribute to generating a better user experience. 

If you want to get more out of reporting with Jira, let us help! As an Enterprise Platinum Atlassian Solution partner, Praecipio Consulting has spent over a decade working with the Atlassian suite to build, implement, and activate best-in-class solutions. When it comes to Jira and other Atlassian tools, we've got you covered!

SmartGrid technology is the effective future of the electric power industry. Just consider the numbers: the US SmartGrid market is expected to double in size between 2009 and 2014, from $21.4 billion to $42.8 billion, with global SmartGrid spending exceeding $200 billion in 2015. With significant aid from federal stimulus funding, SmartGrid development and implementation has already begun across the US. Experts expect SmartGrid technology to become the electric industry standard within 20 years.

You’re probably familiar with what SmartGrids can do. If you’re not, think improved energy consumption information + customer empowerment. SmartGrids leverage automated power systems that monitor and control grid activities, ensuring a constant two-way flow of electricity and information between plants, consumers, and points in between. That information will originate from millions of data points scattered among system devices, enabling utilities to adapt electricity delivery to usage patterns. Demand-response software will enable utilities and consumers to turn high-demand appliances on and off during peak demand periods, improving efficiency. Technology can allow consumers to monitor their home’s energy consumption at the appliance-level (dishwasher, refrigerator, etc), and adjust their thermostats and other power-consuming devices via computers and mobile phones. Basically, SmartGrids will allow consumers and grid operators to understand what’s going on demand-side and make grid management more intelligent.

Information technology (IT) is the driver of SmartGrid technology. Custom software, data management, systems integration, and data security are critical to SmartGrid operations. We bring these solutions to utilities en route to SmartGrid deployment. If you’re making the move, talk to us. We prepare companies for the switch.

We recently heard a traffic analyst from the Texas Department of Transportation (TxDOT) speak about traffic analytics. Living in a city with the fourth-worst automobile traffic in the US, the topic was particularly engaging.

The analyst spoke about the need for data management in traffic analytics. Using traffic-counting devices placed strategically along Austin’s freeways, TxDOT collects data at fixed intervals each day. These data points can be programmed to collect relevant data – in this case, average vehicle speed and highway capacity – allowing the business to know more about their problems and facilitating more appropriate solutions. TxDOT’s data points help them analyze Austin traffic patterns and identify consistent problem spots. They can then, with clarity, allocate funding toward the most effective solutions.

On a smaller scale, we spoke with an insurance agent last week who mentioned the wealth of documents he stores online for his firm’s clients. The firm stores every piece of client information in a digital content management suite – which in the insurance practice equals a lot of documents. While the initial process of digitizing client forms and documents might have been tedious, the firm can now intelligently access (or allow their clients to securely access) client information almost instantly. Moreover, the digitization process was designed and tested at the beginning, making the regular digitization tasks repeatable, predictable, and fast – thereby making the business more intelligent.

Businesses have always found ways to make their processes more efficient to improve their bottom line. These examples show us how businesses are doing so with technology – and how footing the bill for it now can earn a healthy ROI later. Whether you’re a large enterprise (like TxDOT) or a small one-shop business (like the insurance agency), technology can help you save cash by saving you work. In the same way organizing your desk may help you be more productive, saving your employer money, organizing your business information may help your business be more productive, saving the business money. And in the same way TxDOT uses data points to identify problem spots, you can use data points to analyze problem spots in your own business.

Process management applies to the business at all ends. And the profit’s in the process. Good technology can improve process; good process can improve profit; good profit is just plain great. For the transportation firm, custom technology prevents them from having to mine through data every time a particular piece of traffic data is needed. For the insurance agency, a well-built content management system (CMS), or a software that holds and manages your business information, saves employees a wealth of time and money by merely making their information easier to find on the fly – in addition to making it available anywhere and reducing overhead.

Good technology, good process. Good process, good profit. We love improving business process – and since it’s relevant anywhere, it’s a little hard to keep our minds off it sometimes…

Want more? Contact us here.

Image courtesy of Patrick Lane Photography.