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
Sprints, by definition, are a timebox. You’re supposed to say, “Pencils down!” at the end of the sprint, show your work and reflect. One of the big problems with new-to-agile teams is their inability to finish work inside a sprint. Each team is unique. However, I’ve seen these causes most often: Team members multitask, so
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
People often ask me, “When is agile right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile. That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You
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
This is the last in this series of organizing the agile program management posts. It won’t be the last of all the posts, it’s just the last in the series of organizing posts. If I’d realized how many words I was writing in each post I’m not sure I would have started the series. Yes,
I’ve been talking to people whose management cares about their velocity. “My management wants us to double our velocity.” Or, “My management wants us to do more in a sprint.” Or, “My management wants to know when we will be a hyper-performing team, so they want to know when we will get 12x velocity like
I’ve been working with folks making their transition to agile. One of the hardest transitions is for the managers and technical leaders. Managers are accustomed to working in timeboxes. To them, the iteration is a timebox. But, they also are accustomed to features spanning multiple timeboxes, and that’s not OK in agile. They are accustomed
Agile projects, especially if you are starting your agile transition, can have plenty of problems. Some are technical debt problems, such as the build taking too long or having insufficient automated tests to know if your changes are helping or hurting the system. But there’s another insidious management problem when many teams transition to agile: