Tracking and Monitoring

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

Project management specialist Willem-Jan tells a story of a team that he led as a scrum master. The team got fixated on the velocity metric and later couldn't handle complex tasks. On the other hand, management thought that it was helping Willem and his team to get the backlog executed faster. The idea was if the team was self-improving, the velocity at which work is done should also increase. Willem then realized this just deviated the team further from the scrum goal. The episode covers the repercussions of getting fixated on the velocity metric and the lessons that Willem learned to offset the 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.

Defining when the Product Increment is considered “Done”, what to look for and the typical patterns used to measure it.

Sjoerd Nijland talks abt the product increment and the definition of done citing that most teams deliver products in one shot and consider them done but the Agile author argues that this only ends up in getting something that is barely good enough but not perfect. He also adds that a done product is that which we keep on improving to perfection through learning and adapting. If your goal is to learn about the characteristics of a 'done' product backlog and increment plus the definition of DONE and its key benefits to Agile teams, this article is a must-read.

Avoiding the trap of eroding sprint goals so there will be motivation to take corrective actions to prevent future failures.

Anshul Kapoor uses the analogy of a frog and boiling water to pass fundamental lessons Agile teams can learn to avoid sprint goal failures. He notes that like a frog in slightly warm water, Agile teams get comfortable with a few sprint goal failures, and the more the situation persists the teams' failure tolerance levels increases putting the organization into the trap of eroding goals. The same case happens to the frog if you continue heating the water. It tolerates the temperatures and boils along with it. Let's read this interesting article for more insights into how Agile teams relate to a frog in warm water, and what we can do to deal with the trap of eroding goals.

Individual performance metrics may destroy morale and kill teamwork, if used wrongly, but their absence hurts even more.

Project founder and programmer Yegor Bugeyenko, criticizes the modern way of management claiming that programmers have way too much power over projects than managers exempting them from individual performance metrics and that should not be the case. Moreover, they believe that putting a metric on them is a bad practice as it might have negative effects on the team and the organization at large. However, according to Yegor and other Agile experts, individual performance metrics seem to have a positive and contagious effect on all the other members of the team when used correctly. Read the article for more information on why we need good performance metrics in organizations and how to choose them.

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.

Why burn-downs and velocity slow down your team.

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.