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.
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.”