 Hi, my name is Jacob Schatz and I want to show you one new powerful feature of GitLab. Today we will be looking at the Burndown chart. A Burndown chart shows you how much time is left versus how much work in a given milestone. And it shows this data over time. To summarize, if you don't know, at GitLab, one milestone represents one release cycle. So when we go from version 8.16 to 8.17 of GitLab, all of the work contained in that release will be represented in a milestone. Every milestone will be labeled something like 8.17 to represent all the work that needs to be done in 8.17. Each piece of work that needs to be done is represented in an issue. The problem that you need to solve is stated in the issue and the conversation happens in that issue. All these issues work together towards one large milestone. Let's take a look at an example of a Burndown chart in GitLab. Let's choose one of our projects to work with. I like working with our sample HTML5 boilerplate. In this project, I can go to Issues and within the issues, you should see the milestones. Let's take a look at milestone version 2.0. When I click on the milestone, it gives me lots of options and details about this milestone. In the sidebar, you can see how much of the milestone we've completed using this progress bar. You can see the total number of issues for this milestone, and you can see the total issue weight for all of the issues. For this milestone, there is no weight because it's a brand new milestone. You can also see the number of merge requests in this milestone and the finer details of what has been opened and closed. This milestone does not have any due date, and when we add a due date, it will show the Burndown chart for this milestone. Let's choose a milestone that is already underway and has a bunch of open and closed issues and a due date. We can click on milestones. Let's choose the Sprint milestone. This Burndown chart can be filtered by issues or issue weight. As a developer at GitLab, we can get a taste of how the whole team is developing features and when they are finishing them. As a manager, I can see if the release is on track, and I can do all this without having to ask any developers for information. And those developers don't have to log any information. It all happens automatically. As I mouse over, you can see how many issues are left based on the date. The dotted line represents the line to our end date and goal. With this tool, I as a manager can really get a sense of how the developers are developing and whether or not we are on track to meet our goal for this milestone. This allows the developers to keep developing and allows me to get a really great insight into their development process.