I'm here with Bill Wake, a veteran of 15 years, over 15 years I think it is, in Agile, and a major thought leader and contributor to the space, thanks for joining us Bill. >> Hi Alex, thanks. >> Let's talk about burndown, what is your point of view on that, and do you see it work well for teams or not well? And what do you suggest typically for teams on this? >> I'm not all that fond of it per se, because, I mean, it sort of assumes we know all the things that we're going to do for this project. And then as we do them we'll get down, and eventually it's down to zero things left to do and we can ship. And for some projects that's probably reasonable enough. If we're replacing feature for feature an existing system, and here's the 100 features we have and how many have we shipped, and when we get them all shipped we're done. It makes more sense if you're doing something that's more exploratory, you tend to be more like, we burned down some and then we find out here's new things we should do. And you go up and down, and eventually you decide you're going to ship, it doesn't feel as good to me. It's not built in to say we're just going to go down in one direction. And the variation, it represents the learning we're doing. If you pretend that's not going to happen, and your plans are built around just going down a linear way, it's going to be a misfit. So, I do feel like, I like to see visualizations to help me understand how my project's going and what we're doing. But it's just burn downs one of the ones we can use, and there are others. So, we sometimes have maps of stories, there are different forms of story maps you can do that track the progress on developing some stories and identify which ones are critical, and which ones are less important. Other times we're just measuring, how quickly can we turn things around. So, in a peer support organization, we can do this kind of very combine approach that says, things come in and how long til they're delivered? We can do the same thing for some product organizations, too. The key driver is how quickly can we learn, not so much, did we have the right higher things at the start. >> Well that's some great advice on managing work in progress, and the puts and takes of burndown. Thanks Bill.