Adam Gonnerman

Some of my most rewarding professional experiences have been in leading teams through Agile transformations, adopting scrum. I've guided not only engineering teams through this transition, but even business and operations groups such as the archivists at a major media company. Very early at a publishing company a supervisor told me that "we won't do Agile" because people with our brands "need deadlines." He believed that Agile meant 'loosey-goosey' and inefficient. He also believed that we wouldn't get good metrics from a scrum team. That's definitely not the case, and in this piece I'll provide a brief overview of 3 metrics that I believe should be observed and reported. First, the sprint and release burndown will provide a view of the team's progress at a glance. This chart is a representation of the effort remaining over a period of time, and if updated on a daily basis it can help the scrum master to predict whether the team will

While most of the Agile transformations I've guided were into Scrum, there have been some Kanban teams along the way. If done poorly, Kanban is merely understood as a task list on a board shared by a team. That really isn't the way it's supposed to be. Today I'm going to outline briefly the metrics to look for in Kanban, which should provide the insight needed to do a proper transition to Kanban. While I'm making the assumption here that the reader already has an idea of what Kanban is, here's a succinct description provided by Atlassian : Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time. The first metric to look for in Kanban is cycle time. With cycle time you are measuring how long a task remains in process before completion. If