Episode 137: The State of JIRA with Jake Brereton

The Agile Revolution Podcast

Craig sits down with Jake Brereton from Atlassian who is the Senior Product Marketing Manager of JIRA while roaming the product halls at Agile 2016 in Atlanta.

  • JIRA is no longer just JIRA, now people outside of software are using it – now JIRA Software (that includes JIRA Agile), JIRA Core (lightweight version of JIRA) and JIRA Service Desk
  • Over 70% of users were using JIRA Agile
  • JIRA has over 1,000 addons in the Atlassian Marketplace, some exciting work being done around analytics and data
  • Many organisations are starting to question whether they need to adhere to all of the practices and overheads – find the way that is most efficient and productive that works for you
  • The double-edged sword of how configurable and customisable JIRA is – improved onoboarding experience, test instance with demo data and an active online presence
  • Acquisition of Status Page
  • Launched JIRA Software Mobile and…

View original post 5 more words

Episode 113: GreenHopper Handyman Folio with JC Huet

The Agile Revolution Podcast

JCHuetCraig and Renee, sitting on the banks of the Potomac River on a sunny but slightly windy day at Agile 2015, they catchup with JC Huet, creator of GreenHopper (renamed to JIRA Agile and post-podcast now JIRA Software) and Tempo Folio:

  • Craig was apparently the first client of GreenHopper that was built in a basement, now JIRA Agile is the most popular JIRA add-on with over 500,000 users, used by more than 80% of JIRA users
  • the idea was to have a tool that brought bugs into software management
  • the name GreenHopper represented the Green company branding at the time, and Hopper was for cards hopping between columns
  • a shout out to our friend Nick Muldoon (who is now writing Atlassian plugins at Arijea)
  • Tempo Folio plugin is about supporting cost management, including time sheeting, estimation, forecasting and allocation
  • time and dedication and about three months is…

View original post 34 more words

Mik Kersten on Current and Future ALM Trends

InfoQMik Kersten talks about current and future trends in ALM and the support for approaches like large scale Agile, DevOps, Docker, Big Data, functional languages and the Internet of Things.

mik-largeSource: Mik Kersten on Current and Future ALM Trends

Lean Metrics & Time Tracking

Lean MetricsAt this month’s Agile Brisbane meetup, Ben Starr presented on Lean Metrics. His talk was based on metrics that they tracked at his previous company on an operational support team. A couple of points from the talk:

  • used Kanban – work item types to allocate capacity and 3 levels of service (standard, coordinated, expedite)
  • JIRA was the tool but was not the most ideal choice and not really up to the task
  • reported by type on backlog, work in progress, throughput (number of work items not size), velocity (throughput and velocity were similar which showed average size), cycle time, class of service mix, due date performance, estimation accuracy, cancelled WIP (started and then cancelled work) and demand balancing (clearing out the backlog)
  • flow efficiency – percentage of time you work on an item versus in progress, also referred to as touch time – using time tracking in JIRA to do this
  • time allocation – value add, failure load (defects), transaction cost (overheads of planning and releasing), coordination cost (management), used percentage of time spent rather than actual hours

The one things that got me thinking during this presentation was the flow efficiency report.

Early on my journey of being an Iteration Manager, my teams used to track times per card. We used to use XPlanner which had some reasoanbly easy functionality for tracking time (one of the good features was as the Iteration Manager I could enter time for my team if needed, tools like JIRA require the developer to record that data if you want it assigned to that developer). We used to use thee metrics for comparing estimates to actuals but over time I came to the conclusion that we would be much better off just making sure that the cards were completing on time (an average of 3 times) and splitting cards out if they appeared to big.

Lately, a number of people in my Agile classes have been arguing that time track is beneficial. My usual response to this (like for all metrics) that it is OK if it adds value, but my recommendation is not to waste your time. Even more so, this opens up the estimation debate that I also believe that a lot of time should not be wasted on (#noestimates), but that is a discussion for another post. My main reasoning is often we need to track for other sources (like timesheets) in different systems, and the overhead does not justify the effort. If teams need time metrics (often to see if time is being wasted away from the core work of the team, say on production support or corporate meetings), I suggest they are done at a team level and rounded to the nearest hour, and collected as time not spent not on project work.

In the graph above, flow efficiency is a good way for showing waste in the system (in this example, the team could potentially be way more effcient), but it relied on the team tracking time (in this case using the time tracking feature in JIRA against each card). I really like it as a graph, I am just not sure the effort to produce it is justified.

Some discussion in the Q&A revolved around recording time tracking (or similar metrics) is OK if the team understands it is an incentive for better metrics, and I can’t disagree with that thought. Just in my experience as an Iteration Manager, getting reliable and timely time and effort metrics ha been painful and the reward outweighed the effort.