In preparation for a recent consulting engagement, the client, Tim, said, “I want you to track meeting attendance. If people don’t come to your meetings, I want to know why.” Tim was worried about the cultural changes we needed to discuss for the client’s ability to be more effective. Tim had good reasons to worry […]
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points?
I’m not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.) Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish
Part of what makes an agile transformation difficult is the cultural change required. That’s what makes an agile transformation a journey. A client said to me, “I want the agile. The agile is good stuff: faster delivery of smaller stuff that we can get revenue for. I want it now. How fast can I get
I’ve been thinking more about possible measurements in an agile transformation journey. The first Possible Measurements post focuses on product throughput measurements. This post will focus on measurements you might see when the culture changes with an agile transformation. Again, do start with your why. Without knowing why you want to use agile approaches throughout the organization,
“What should I measure???” is one of the questions I see when I work with people going through an agile transformation. Too often, managers measure people as individuals. (Traditional measurements focus on resource efficiency instead of flow efficiency.) Resource efficiency measures don’t measure what the organization delivers or what prevents the organization from delivering. This
See Your Agile Measurement Traps In honor of my new book, Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, this is the second in a series of four trap emails, the measurement trap. Here are three common measurement traps: You/your management thinks velocity is a target or a measure of progress. Someone (often a
Program sponsors and the teams themselves want to know where they are in the program. What’s started? What’s not? How much more remains? It’s tempting to measure “everything.” That creates another problem: You might spend too much time attempting to gather data that doesn’t provide enough information. You might even miss seeing the real progress
I see a lot of confusion around velocity in new-to-agile teams. Too many people treat velocity as an acceleration measurement. That is, they expect velocity to increase to some large number, as a stable state. Velocity is a rate of change coupled with direction. When managers think they can measure a team with velocity, they
I met a team recently who was concerned about their velocity. They were always “too late” according to their manager. I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they