minware Overview

Welcome to minware! This guide gives an overview of minware reports and functionality for first-time users. It assumes that an admin has already hooked up source integrations and set up your organization’s account.

What is minware?

The goal of minware is to provide total visibility into your software development process.

Reports from tools like Jira and other analytics platforms all have major gaps that make it difficult to see what happened, understand why, and improve.

minware fills those gaps with our unique time-native data platform, which is based on multiple patents. It differs from traditional data platforms by modeling the full history of all your engineering data (Git, tickets, and more) to create a complete historical timeline. It also gives you the power to do custom analysis on this timeline with the minQL query language.

This lets minware answer questions you really want to know, like how much active development time went into fixing bugs, not just how many bug tickets were closed.

You can think of minware as a bridge between traditional sprint reports and reality when the two diverge.

Supporting an Impact-Driven Culture

minware is designed to foster an impact-driven culture that thrives on continuous improvement and achieving results.

We believe that transparency and total visibility are essential for realizing this impact.

Total visibility will expose problems you didn’t know about and raise questions no one is asking.

For visibility to be a positive force for change, we recommend following one very important rule:

Metrics provide visibility, managers make judgements.

To put it another way, metrics should support the judgement of a manager, not override it.

Managers simply have more context from their interactions with people. Building software is a complex activity with many nuances and unique situations. Metrics handle common cases well, but a person needs to have the final say about what they mean and what to do.

This is essential for maintaining focus on outcomes rather than optimization for its own sake, which can happen if people chase KPIs without thinking about the bigger picture.

Time Model

One important concept that underlies nearly all of minware’s metrics is our unique time model. Our time model combines data from Git, ticket, and calendar systems to determine how much work time went into each commit and ticket.

We use this model to achieve more accurate results than other reporting tools that just count things like lines of code, commits, pull requests, or story points.

The Dev Days metric measures active development time only. This time is allocated based on gaps between commits each day, excluding meetings. For example, if someone regularly works 9 AM - 5 PM and commits twice at 1 PM and 5 PM with a meeting from 2-3 PM, the model would associate ½ dev day with the first commit, and ⅜ dev day with the second commit. These dev days then roll up to branches, tickets, and epics/projects through links in the data.

The Work Days metric further measures non-development time between active coding. The model associates non-coding time with tickets based on when they were created, assigned, and changed status.

Both metrics allocate 5 days per week and are agnostic to total hours worked, which aligns with the salaried employee model.

Work Days typically include 5 days per week to fully account for each person’s time, but may have gaps if people are out of office or have no ticket activity for more than a week. Dev Days will be less than 5 per week since it only counts active development time. A typical full-time engineer will be actively coding about 50% of the time.

See the time model documentation for more information about how Dev Days and Work Days are computed.

Pillars of Software Engineering

minware’s reports are organized around helping you improve four main pillars of software engineering:

  1. Quality - How many defects are we creating, how fast are we fixing them, and how difficult is it to modify or build new software?
  2. Efficiency - How much effort is lost to overhead from inefficient processes, inadequate planning, and interruptions?
  3. Predictability - Are we able to consistently deliver on commitments to customers and the business?
  4. Value - What did we accomplish, how did it align with priorities, and how much effort did it take?

While there are many things to consider under each pillar, this structure helps break down the complex task of building software into more manageable areas of focus.

Reports and Dashboards

When you first view minware, you will see several default reports under the “dashboards” heading in the main menu. Those reports are as follows:

  • Scorecard - The scorecard contains foundational metrics that measure adherence to best practices across all four pillars, as well as hygiene metrics that are important for the accuracy of other reports.
  • Time Allocation - The Time Allocation report shows where effort went using the time model in support of the Value pillar.
  • Merge Success - The Merge Success report offers visibility into how code flows from initial commit to deployment in support of the Efficiency pillar.
  • Cycle Time/Flow - The Cycle Time/Flow report analyzes Efficiency from the perspective of ticket and pull request workflow steps.
  • Quality/Bugs - The Quality/Bugs report offers insight into how many bugs you are creating, how quickly you are fixing them, and how well you are managing your bug backlog in support of the Quality pillar.
  • Sprint Trends - The Sprint Trends report offers much deeper visibility into sprint performance over time than traditional sprint reports to help you better improve your sprint practices in support of short-term Predictability.
  • Project Completion - Finally, the Project Completion shows you progress on projects that may span multiple sprints to improve long-term Predictability.

Below the default reports, the “Explore All…” link takes you to the full report library, which has a wide variety of reports covering more specific use cases like cost capitalization, CI/CD performance, and more.

Customization

One of the main things that sets minware apart from other analytics platforms is the ability to customize out-of-the-box reports or create your own.

You can see how any chart was created in an existing dashboard report by clicking on its title. This takes you to the custom chart builder, which you can also reach by clicking on “+ New Chart” in the main menu.

The custom chart builder has an interface similar to business intelligence (BI) tools or pivot table configuration in a spreadsheet.

Here you can select the chart type (or table), add metrics to the main axis, breakdowns to the chart series, and filters to narrow down the result set.

See the custom report builder documentation for more information about custom charts and building dashboards.

minQL

Every value in the chart builder is written in minQL and fully editable.

minQL offers the power of SQL with support for a full range of database functions, but is much easier to use for querying time series data. For example, you can see how many dev days occurred during different ticket statuses by adding the minQL breakdown: ticket.getOrig('status').

minQL has access to all fields from your original data source, so you can build expressions referencing labels, status, etc. and avoid having to clean up data in your source systems.

See the minQL documentation and minQL function reference for more detailed information about how to use minQL.

Also, please don’t hesitate to contact support@minware.com if you would like help with minQL. Almost anything you can do in SQL is possible with advanced minQL features like window functions and state machines, but, like with SQL, there is a bit of a learning curve.

Next Steps

With a basic understanding of how minware works and what is possible, we recommend taking a look at these guides for using minware to improve specific areas of software development.