Introduction​

We've recently started adding new features to NitroIQ that help you identify performance issues in JIRA, and provide you with actionable insights to help you resolve them.

To that end, we are adding an entirely new section of best-practices and help to the NitroIQ online documentation. The aim is to help team leaders identify performance issues in their teams and processes and provide them with prescriptive guidance, using their own data, on how to resolve them.

Measuring Sprint Velocity and Burndown (or Burnup) is common practice in agile shops. It allows leaders to better resource and capacity plan, because knowing what your teams' past performance metrics, is a decent gauge of future performance in upcoming sprints.

Agile Churn: When changes in the list of tasks or scope occur during a Sprint (or iteration).

Churn in sprints is inevitable, but should not be a consistenly occuring event. Stories being added, removed, or story points being adjusted mid-sprint are a fact of life in a dynamic Agile environment, but minimizing disruptions to the team and deliverables should be the goal of every Agile lead.

More fun with JIRA data. ;-)

Can the number of status changes in a given Jira Issue be an indicator of missing or confusing requirements, bad resource management, or other team deficiencies that can affect sprint performance?

I've long run my teams using metrics calculated mostly using JIRA JQL and spreadsheet gymnastics. One of the most practical measurements of forward progress I've come to rely on is what we call "Innovation Rate", which is seeking to describe how much time is my product/engineering team spending on New Features compared to maintenance tasks or bugs.

I learned a lot while building and leading the engineering team at Predikto. Aligning and integrating data science in to the software development process was something relatively new in the industry (because, "AI"). This is something that I believe the team got "right" after a lot of hard work and wrong turns over the years. I think we finally got our method of operating and aligning right when it lead to a great product and a even greater exit.

TLDR; On startup acquisitions: Your culture will change, intentionally or otherwise. Embrace it. Resistance is Futile

I was recently invited to speak at [McKinsey's Digital and Analytics Summit](https://solutions.mckinsey.com/msd /dnasummit/), where I focused on digital disruption in large corporations, innovation labs, and startup acquisitions. Having experience over the years with startup acquisitions, I've had front-row seats on the good and the bad (mostly bad) ways in how they've taken shape. This short series is meant to be a landmine map for startup employees and founders, of the most common missteps I've witnessed post-acquisition, in contrast to the talk I have, which was focused on what corporate leaders could do differently after a startup is acquired to help preserve and grow their investment.

Short blog post on some of the most common mistakes I’ve experienced with the recruiting and hiring of top talent engineers. Although there are many articles written on how to attract and hire great talent, seldom is there word shared over the silly things companies do to shoot themselves in the foot during the hiring process.

“If you think it’s expensive hiring great engineers to build your software, wait and see how expensive it gets with bad engineers.”

As a long-time user of ElasticSearch, I’m proud to announce a new project I’ve undertaken, ElasticHQ – an ElasticSearch Management and Monitoring solution that is 100% browser-based, ie. No software to install.

Those who know me, would note that this is a departure from my usual style of coding and architecture, but after studying the ElasticSearch Java API (mainly TransportClient), I decided it would spur mass adoption if the application was run on the client (browser). So using Backbone.js, Underscore.js, Twitter Bootstrap, and Flot charts, I managed to carve out a solid nucleus I can build upon.

Feel free to check it out here: ElasticHQ.org

For those that want to look at the code, you can find it on Github, under ElasticSearch-HQ. There is also a Google Group, although not advertised yet.