Welcome back to our Scrum course. In this lesson we are going to discuss Scrum reporting. So with Scrum reports, Scrum reports involved data that track how the team is doing with the Scrum process. It is important that teams still continue to use their own metrics to track improved business results with the Scrum practices. Scrum reports also provide direction related to the team's improvement. So Scrum reports are things like the sprint burn up, the number of points that have been delivered. Also, velocity reports, items such as that. Predictability reporting is very important in Scrum, so teams need to know how predictable they are, so they can better estimate or they can try to improve an estimation. So predictability reports measure for accuracy and estimating the number of story points completed. And also they can help us with improvement as far as the number of stories that are moved to the next sprint. All of these are indicators for improvement in making better estimates. Burn down reports are a very, very popular Scrum report. With burn down report, the team has some kind of a plan, so they go into a plan, usually with the with the X axis. It's time, usually days of the sprint and the Y axis has some kind of effort, usually points. So if the team has a sprint that is 28 points, and in this case it's going to be 20 days. We are going to see that we, just a straight very constant decline. So the work remaining here, a burn down chart gives us the work remaining versus the amount of time remaining. So on day zero of the sprint, we have all the points remaining, all 28 points remaining. By the end of the sprint, we have zero remaining. So that's what gives us this very constant type of line here. So this is our estimate or our plan line. Then we get actuals, and any time our actuals are trending above the plan line, it is saying that we are behind plan. I don't like the term ahead, behind schedule because you're always on schedule with Scrum. But it's used quite often. It's used in most of the documentation, so we'll just go with it here. Here if this trend continues, the team may have to take action sooner rather than later to reshuffle the deck so they can deliver a working solution increment by the end of the sprint. But notice here suddenly this changes. And now our actuals are trending below the plan line, and that tells us that we are ahead of plan. I like to say ahead of plan, and this means that we can, not slowed down but be a little more thorough, and do our best to deliver all of the points by the end of the sprint. Now that this could change. So this needs to be watched very closely by the Scrum master and the rest of our team. But again, the burn down chart tracks the amount of work remaining versus the time remaining. It has an ideal remaining effort or a plan line, as I like to call it. And then we have our actuals. When are actuals are above the plan line? We are trending behind plan. When our actuals are trending below the plan line, we are trending ahead of plan. And there are also burn up reports, so burn ups also track the status of our sprint. A burn up chart is a tool used to track how much work is completed in the time of the sprint. So burn up reports also show the total amount of work remaining in the sprint. So if we take a look here burn, we can see here that we also have a, we have our plan line, and we have our actuals here in our to dos. And we can see how we are trending. We can either trend ahead of schedule or ahead of plan, or behind plan. So again, we have our scope here. We have our to do, and we can see what we actually have done. So we're tracking are done here. This green line is are done and again, we can see where we are trending behind plan, and also ahead of plan. Velocity charts also are important. Velocity charts track the number of stories estimated for a sprint versus the number of story points actually implemented or actually delivered. So we can see here the commitment where the estimate for the team in this case is in blue, and we can see in green the actual delivery here. And we can see for this sprint, which happens to be Sprint 1. The team delivered exactly what they estimated. In Sprint 2, the team estimated around 20. But they seems like they came in short, maybe around 14. Again we can see here the team came in a little short of their estimate. But we can see in the next two, they were able to deliver exactly what they estimated. And what the team wants to do here is number one, determine their actual velocity based on their past performance. And also to see how they're doing as far as estimating. You can see in these two sprints, the team did not estimate very well, but in overall they seem to be estimating right on target. A cumulative flow diagram is an area chart that shows the various statuses of the work items for the sprint. So each of these colors in here is actually a section of the team's workflow. So in this case, it looks like they have a lot of states of the workflow. So the colors correspond to again, the states or the columns of the team's workflow in one of the, it's one of the most advanced analytical charts. And it provides a concise visualization of the three most important metrics in your workflow cycle time. So you can see here how when an item enters the workflow, and when it leaves and begins the next workflow, throughput, and we can see also work in progress. So if in this case the blue was done, we can actually get a time when the work item begins one section of the workflow. And how long it takes to actually get to done. A control chart is a graph used to study how a process changes over time. So the data is plotted in time order. It's a tool for measuring the reliability of predictability. So with a control chart, a team can tell how reliable their estimations are. It always has a central line for an average and an upper line for the upper control limit, and a lower line for the lower control limit. So you can see these lines right here, rolling averages. We can see here the upper line and the lower line, and these lines are determined for historical data. So we can see generally what our cycle time is for a, we you can see here clusters and cycle time. You can hover over these, and it can tell us how predictable we are. So if we see here, if our line here, cycle timeline begins to go up, we can see that we are trending away, or it's the cycle time is taking longer. Or if we can see here for our cycle time here, it's actually taking, we're actually picking up progress, so we are completing more. Our work items are going through the process faster. So that's what the control chart is actually tracking, how quickly our individual stories and other work items go through the process. And then these are outliers here. We can see some outliers here. And the idea here is that since these are outliers, we may want to look into these outliers. We can see them here as well. We want to take a look at how we're doing, so it's a way of looking at actuals versus average. Again if we start to go above average, we're starting to slow down our cycle time. If we're starting to go below average, we are reducing our cycle time. And our cycle time again means from when we start work items such as stories, and when we complete them. And it's always important to for a team to report on the metrics that they've always used because we can show improvement there. And some other good metrics, velocity for the whole program, some kind of predictability measure, features that are planned. Stories that are planned. Number of stories accepted. Number of features accepted, a unit test coverage. So testing coverage, meaning that for every story there is a corresponding test case, the number of defects is always good. The total number of tests and the total number automated. These metrics actually help motivate a team, number one, to automate tests, but to improve on all of these metrics. So thank you again for watching this lesson. And in our next lesson, we are going to discuss team collaboration and problem swarming.
