Tracking and Monitoring

Exploring what can happen when teams get fixated on “velocity” metric, and lessons to avoid this anti-pattern.

Going beyond information about status of work, and spotting issues the team may be facing - all with a quick glance.

Cumulative Flow Diagrams can be extracted automagically from many issue-tracking tools, and this simple graph can shed a light on a plethora of information about the team and its work style. From a single diagram, Pawel Brodzinski shows how we can identify common patterns and deduce what the team can be struggling with. A master class on team tracking - make sure to read the comments for more insights.

Turn raw kanban data into actionable flow metrics.

A different take on a related post by Daniel Vacanti, where he shares how to collect data, and to calculate cycle time and throughput, this article focuses on how to turn data into meaningful flow metrics by calculating the cycle time using start and finish times of work items. The calculation helps with prediction of completion time, and measuring the overall performance of your process.

How do you turn your data into meaningful flow metrics

Part of a series of posts from Daniel Vacanti, where he shares how to collect data, and to calculate cycle time and throughput, this article focuses on how to turn data into meaningful flow metrics by calculating the cycle time using start and finish times of work items. The calculation helps with prediction of completion time, and measuring the overall performance of your process.

Considering the multiple benefits you gain from having a Definition of Done.

The reasons for having a Definition of Done (DoD) may vary from team to team, and each person might find a different reason compelling. And others might also have the wrong meaning of the Definition of Done. Learn the true meaning of the Definition of Done and five fundamental reasons for having it during an organizations' development process.

Knowing when you are “Done” frames the work to be undertaken.

In Scrum each iteration - or Sprint - should yield a valuable product increment of release quality. Ian Mitchell advises that an understanding of what makes an increment truly releasable - and therefore genuinely “Done” - provides transparency over the work a Development Team plans to do, and the tasks it brings into progress. Work nearly done puts the team in technical debt, which must be repaid at compounding rates of interest.