Value of Burndown and Burnup Charts

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 “committed” to for each iteration. This is what their burndown chart looked like. A burndown chart measures what you have finished. If you look at their burndown, you can see there are times when not much is done. Then, near the end of the iteration, they finish more. However, they don’t finish “everything” before they run out of time. An iteration is a timebox, by definition. In this case, having to “declare victory” and assess what they were doing should have helped them. But, when this team saw the burndown, two interesting things happened. They beat themselves up for not finishing. And, when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added, not replaced. That meant they never caught up. They tried this burndown chart next, to see if they could meet their ideal. They realized they were “late,” off the ideal line from Day 2. They felt worse about themselves. They stopped doing retrospectives, which meant they had no idea why they were “late.” A burndown emphasizes what you have completed. A burndown with the “ideal” line emphasizes what you have done and what you “should” be doing. I have used story...

How Long Are Your Iterations? Part 2

When I teach agile, I explain I like small and short stories. I want to see value in the product every day. Many developers can’t do that. That’s because they have interdependencies with other teams—not developers on their team, but other teams. They can’t implement in the way the picture next to this shows: small, coherent slices through the architecture. Instead, they implement in curlicues. When you implement by curlicues, you often have to wait for other teams. You might have component teams. You might have performance teams. But you can’t implement in nice “straight” features. Your features are complex and don’t take a straight line through the architecture. When I work with people who have curlicues instead of straight lines through the architecture, I often discover that the different teams can complete parts of features in one iteration. (It doesn’t matter how long the iteration is.) But completing an entire feature? Because that takes the efforts of several teams, the team members believe they have interdependencies and the full feature often takes longer than one iteration. The teams are correct. They have interdependencies. Sometimes, those interdependencies are quite difficult to see when you start. You only know that they exist when you get stuck partway in the feature. Implementing by curlicue creates delays. The iteration is not the two weeks, three weeks, four weeks. No, the iteration can be as long as eight, nine, or ten weeks. That’s because each piece of the curlicue has to get to the top of each team’s backlog. The teams might have different product owners who don’t realize each arc of the...

How Long Are Your Iterations? Part 1

I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks. I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported defects post-iteration? He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I’ll address later.) Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours. The developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don’t finish. I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing. “Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.” I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing. “Oooh.” He...

Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything

The discussion to now: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability When you move from resource efficiency (experts and handoffs from expert to expert) to flow efficiency (team works together to finish work), everything changes.   The system of work changes from the need for experts to shared expertise. The time that people spend multitasking should decrease or go to zero because the team works together to finish features. The team will recognize when they are done—really done—with a feature. You don’t have the “It’s all done except for…” problem. Managers don’t need to manage performance. They manage the system, the environment that makes it possible for people to perform their best. Managers help equip teams to manage their own performance. The team is accountable, not a person. That increases the likelihood that the team will estimate well and that the team delivers what they promised. If you are transitioning to agile, and you have not seen these things occur, perform a retrospective. Set aside at least two hours and understand your particular challenges. I like Agile Retrospectives: Making Good Teams Great, Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises, and The Retrospective Handbook: A Guide for Agile Teams for creating a retrospective that will work for you. You have unique challenges. Learn about them so you can address them. I hope you enjoyed this series. Let me know if you have questions or...

Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability

This is the next in a series of posts about resource efficiency vs. flow efficiency: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability: Accountable to the project for finishing their own work Accountable to their team for participating fully by doing their work Accountable to help other people learn what they did by documenting their work Accountable for meeting their estimates Accountable for how the project spends money … There might be more accountabilities Let’s take the first two together: Accountable for finishing their own work and by doing their work I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?” Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet. Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something. So the part about “own work” seems a little micro-managing to me. The part about doing their work is a little trickier. When people get stuck, what do they...