 Hello, welcome to the session on Burndown Chart in Scrum Methodology. Let us see the learning outcome. At the end of this session, students will be able to use Burndown Chart of Scrum Methodology in software development. A Burndown Chart is a graphical representation of work left to do versus style. It is often used in agile software development methodology such as Scrum. However, Burndown charts can be applied to any project containing measurable progress over time. The Burndown Chart is a chart that shows how quickly you and your team are burning through your customers' user stories. It shows the total effort against the amount of work we deliver each iteration, something like this shown. Burndown Chart is a common and useful tool usually used in stand-up meetings. Not only in stand-up meetings, to assess how much work has been completed on an assignment. I personally like to use it as a forecasting tool instead. It gives us a rough idea how we are doing in the current sprint. The simple, visually-appearing format is used by many agile practitioners because it can be easily understood by all team members. Burndown charts are used to measure how much work has been completed on a project during a specific time frame, then compared to the amount of time still available to complete the project. They outline the amount of work planned versus what is performed during each iteration. The charts are highly useful tool used to monitor completed work and work that still needs to be done during the designated time frames. However, as useful as they are, Burndown charts have their limitations. They cannot, for example, clearly or effectively measure work that is still in the progress. They only measure what has already been completed, so that is one of the limitations. So it clearly or effectively measures work that is still in progress. They only measure what has already been completed. Let us see an example of Burndown chart as shown. It demonstrates an example of work completed versus work that can be delivered during each iteration. You can see by looking at the graph that the left side shows the total effort while the right side shows the team velocity. This graph also provides the following information. Work completed during each iteration. Work still needed to be done. Time frame when the team expects the project to complete. While this chart is very clear and easy to follow, it's not necessarily realistic. A true Burndown chart will not have straight lines showing the time frames because the team will never complete their task at the same speed or in the same time frame. Burndown charts are highly effective tools with many strengths. However, there are weaknesses as well to using this chart. Pros of using the Burndown charts are, Burndown charts are simple, easy to follow, easy presentations. They clearly show an agile team's achievement, clearly show what the team still needs to achieve. Let the team know if they are on target with their deadlines. Alert the team to potential problems or bottleneck situations quickly. Show the progress of the project. Students can see where they need to focus their efforts to get back on track, motivate the team, show the team where they have succeeded and work they still need to do. Let us see the limitations. They are limiting. The chart only shows the part of the total picture. They do not show what tasks are still in the progress. They do not show how close the team is to complete their work. They can lead to exaggerated expectations that is worse than the reality. Teams that run aggressive projects based on unrealistic or over-inflated time frames can become easily disgruntled or lose their motivation when the project does not run smoothly. The team can also lose morale if they feel they are being micro-managed. Any information that is not covered in the Burndown chart should be addressed in the Scrum meeting. So the team has a clear picture of how the project is going. To effectively create and use the Burndown chart, the team must first implement a task breakdown. This usually happens at the sprint planning meet. Each task identified in the breakdown should have an allotted amount of time designed to complete the task. Ideally 12 hours is the best amount of time. This can be broken down into 2-6 hour days. Once the task breakdown has been completed, the team can then create and plot their Burndown chart. If the team assumes that each task will be completed at the same rate as the rest of the task, then their ideas should reflect their steady progress. There are many agile tools available with built-in Burndown chart abilities. Some of these tools include Rally, RTC, Version 1, and Mingle. If you do not have any of these programs, an Excel spreadsheet can be used to create a Burndown chart. On the spreadsheet, input the sprint dates on the x-axis and the remaining efforts on the y-axis. Let us see an example of an ideal Burndown chart shown. In this example, the sprint is 2 weeks. The team consists of 7 members working 6 hours per day for a total of 4-20 hours. As you can see, the total hours for the entire sprint are shown on y-axis. The green line shows that what the ideal work progress should be during the sprint. If we assume there will be no problems or delays, all the tasks should be finished by the end of the sprint. This example demonstrated another Burndown to chart the team progress during the sprint. You can see that the green line shows the progress that has been completed while the black line shows the remaining effort needed to complete the project. Let us see the release Burndown charts. Some projects can use release Burndown charts to track their progress. The Scrum Master is responsible for updating the release of Burndown charts at the end of each sprint exercise. On this chart, the horizontal axis that shows each sprint while the remaining work is shown on the vertical axis. The teams can use any of the methods they choose to show the remaining amount of work including story points, the team, days and ideal days. We will see the example. In this example, the chart shows that the team started with 360 story points to successfully complete their project in their planned six sprints. The team would have to average six story points for each sprint. For example, this example also shows that in the first sprint, the team used 90 story points with 270 remaining. The second sprint can smoothly as well, however, as you can see in the chart, something happened during the third sprint and the team burned up their story points. Once they resolved the issues in the third sprint, the project ran smoothly for the remaining sprints. Let us pause the video for a while and answer the question. Suppose you are an ideal baseline for using the available hours over the sprint. So in the simplest for this is the available hours divided by the number of days. Create the Burndown chart for these values. So in the simplest for this is the available hours divided by the number of days. In this example, 80 hours over 5 days equating to 16 hours a day. In order to create a project burn down chart, the data needs to be captured as a daily running total starting with 80 hours then 64 hours left at the end of the day. That is 80 minus 16, 48 hours left at the end of the day 2. So 64 hours at the end of the day 1 then 48 hours at the end of the day 2. So these are the following references I referred. Thank you.