Motley says: "What are we burning down? Your house?" (Scrum Part V)

  • Article

  • Summary

  •  

  • Motley:  A burndown chart? What are we burning down? Your house?

  •  

  • Maven: Track time remaining for tasks to generate a burndown. Combine time remaining with time spent to generate a cumulative flow diagram with burndown. Use the charts to get an accurate picture of project progress.

  • ______________________________

  •  

  • [Context: Maven and Motley just arrived at work in the morning and are continuing their discussion on Scrum, this time discussing data analysis]

  •  

  • Maven: Morning, Mot! Want to pick up where we left off in our Scrum conversation?

  •  

  • Motley: Does Superman want kryptonite for breakfast?

  •  

  • Maven: C'mon - this is important stuff. Let's talk a bit about data gathering in Scrum.

  •  

  • Motley: Sounds about as exciting as cleaning the bathroom. I've got stuff to do.

  •  

  • Maven: This won't take long. Previously we talked about the importance of retrospection for a sprint.  You had some questions around why we gathered data during the sprint. Well, the basic data that we gather every day is the amount of time remaining on our tasks. We want to be realistic with our estimates - as we execute, we feed the learning back into the plan and make adjustments. For example, if we underestimated a task and it will take longer than expected, we may want to cut some tasks off the bottom of the priority list to set expectations with our stakeholders that we won't deliver everything we set out to deliver. Tracking our new estimates on a day-to-day basis gives us a burndown chart.

  •  

  • Motley: What are we burning down? I'll bring the matches.

  •  

  • Maven: Time in the sprint. We use the burndown chart to get an idea of how the project is trending and whether we are going to meet expectations. The goal is for the burndown line to reach zero at the end of the sprint.

  •  

  •  

  • Motley: I guess given the burndown and the fact that we were able to complete a certain number of hours in a sprint, we can use that data to help us plan next time.

  •  

  • Maven: See? I knew you were enthusiastic about this! You are absolutely correct.

  •  

  • Motley: Am I never not correct? I thought you would have learned by now, Mave.

  •  

  • Maven: You need a bit more humility, Mot. Like a friend of mine always says about himself, "I'm a 9, because nobody's perfect." Errrr… wait. Maybe that's not a good example. But I digress. The burndown also works on the product level, so that over several sprints you can see how your overall release is trending.

  • Also note that you need not estimate in hours as the chart above indicates. Many agile teams use "story points."

  •  

  • Motley: "Story points"? What the heck is that? I am building software, not telling a story!

  •  

  • Maven: Story points are essentially a unit-less measure that describe the size of a requirement in relation to other requirements. Think of a story as a basic requirement written as a scenario from the user's perspective. The reason we use a generic measure like points is to get us out of thinking about hours. The important concept here is that we understand how much work we can do in a sprint, i.e. our velocity, and use that measure to plan future sprints. Story points remove the focus on time and remove the desire to compare across contexts or other teams. The story points become unique to the particular team.

  •  

  • Motley: But how could I possibly have any idea how many "points" a feature will take to build?

  •  

  • Maven: It's tough at the beginning when you don't have anything to compare to. Once you know your team's velocity and how many points you can deliver in an iteration, it becomes more natural.

  •  

  • Motley: Sounds interesting, but I think I'll stick with hours, thank you very much.

  •  

  • Maven: That's fine - whatever works. Let's get back to the data. While the burndown chart is very useful, you can generate much more valuable data if you not only track time remaining on tasks during a Daily Scrum, but also track time spent.

  •  

  • Motley: You have got to be kidding. Tell me you're kidding. You want everyone on the team to report time spent as part of their status?? I am telling you right now that no one on the team is going to like that. They will feel as if their manager is closely tracking every hour of their day. It will lead to micromanaging, morale will decrease, and people will be afraid to take a break. Not going to work.

  •  

  • Maven: I admit, it's controversial, and to be honest, outside the core Scrum process. However, you get much richer data. Plus, the data is for the team only - no one outside the core Scrum team gets access to the individual data. All that matters is the roll-up of time spent. Let me give you an example of a valuable pictorial representation of the data. The chart below is called a "Cumulative Flow Diagram (CFD) with Burndown".

  •  

  •  

  • Motley: I'm not convinced on gathering effort expended, but the chart looks interesting. Tell me more.

  •  

  • Maven: What do you think happened in this project?

  •  

  • Motley: Well, the red line seems to be the same as the burndown you showed earlier. There was a hump around day 16, which could indicate that the team underestimated or the plan grew. The grey indicates the total combined hours of tasks that the team has not started, the yellow the number of hours of tasks in progress, and the green the number of hours corresponding to tasks that have been completed. This team had lots of work in progress, had a slow start, grew and then later shrunk the plan, didn't finish all their tasks, and had some areas of poor productivity. Lots of things to look at in a retrospective.

  •  

  • Maven: Nice analysis! See how straight forward the chart is to follow? You can get some great observations out of one diagram. You mentioned that the hump may be due to underestimating or plan change. We can tell for sure by coupling this CFD based on hours with another one having a y-axis of number of work items. A corresponding hump in the work items CFD indicates that the plan grew. Notice anything about the yellow area?

  •  

  • Motley: It's big, but I don't see a problem with that.

  •  

  • Maven: A wide yellow area is generally not a good thing. With a chart like this you only get credit for work that is completed. The minute you log an hour on a large task, you end up with a large yellow area. Let's talk about the danger of that large yellow area later.

  • Here is another example of a CFD with burndown:

  •  

  •  

  • Motley: Wow - this team significantly over-planned. They didn't finish many of the tasks they set out to do. There is also a flat spot that we want to analyze. Why was the team unproductive during that time? Was there a major distraction? They did adjust the plan somewhat, but perhaps not enough. Actually, now that I look closer, this isn't a good sprint. Although they had a good velocity throughout the sprint, it lasted way too long and they didn't adjust the plan enough based on new knowledge. Stakeholders may have been expecting more to be delivered by the end if they checked-in midway. Bad Scrum Master.

  •  

  • Maven: Nicely done, Mot. You would almost think you invented that graph.

  •  

  • Motley: I am brilliant, of course. However, I cannot take credit for inventing that graph. They are easy to understand though, provided we can convince the team to track time spent. I'll see what I can do.

  •  

  • Maven: Just reassure them that the data will not be used against them. In addition, it doesn't take much extra time to track time spent in addition to time remaining. It does allow us to get a complete picture of the project over a short iteration and adjust the plan on-the-fly.

  •  

  • Motley: One more thing - I am still not quite seeing why a wide yellow area is a bad thing.

  •  

  • Maven: Let's save that discussion for another time.

  •  

  • Motley: Ah, that's typically code for "I don't have a clue".

  • ______________________________

  •  

  • Maven's Pointer:  There are generally two reasons why wide yellow areas are a sign of trouble. First, it may be a sign that the team has too many tasks in progress at one time.

  • Human beings are terrible at multi-tasking, but more on that later. Second, it may indicate that the tasks on the sprint are not broken down enough. For example, if you put 1 hour against a 40 hour task, you get 40 hours worth of yellow in the CFD. Estimate tasks from 1 hour to 16 hours in length. It is easier to define "done" and shows that you have more completely thought out the task. Otherwise, the team does not really know what is involved in completing that task, and the estimate is far less accurate.

  •  

  • Maven's Resources: