 Welcome to Visual Studio Toolbox. I'm Donovan Brown. Today, we're going to be talking about delivery plans with Elliot. Elliot, welcome to the show. Thanks, Donovan. So tell me, what do you do on the Visual Studio Team Services team? Sure. So I work on Visual Studio Team Services and TFS, and in that team, we work on the Agile group. So that's everything that looks after work item tracking, such as your Kanban boards, your backlogs, your queries. And obviously, our delivery plans. You've got it. So delivery plans, if I understand it correctly, it's an extension that we can add to Team Services today, right? That's right. Yeah. So it came live in the extension marketplace a couple of weeks ago, and we're in public preview, which means it's free for use at the moment. We're really looking to get usage and get a ton of feedback on how we want to make a great experience. All right. So let's show me how it works. Great. Thanks. So what you're looking at here is actually a delivery plan itself. And the purpose of the delivery plan is to view work across multiple teams. And we're answering one key question, which is really when is the work going to be delivered? Okay. So taking you through the view you can see here, you can see at the top, we have this calendar element. And this is a normalized calendar element. So you can see today is the 9th of February, and we've got this today marker, which is clearly highlighting where we are in the calendar. And then below that, we have our team rows. And so what you're looking for here is this is the work that each team has scheduled in their sprints. Okay. So for example, in this team row here, Team 1, we're seeing the features that that team are going to be delivering. Their current sprint is Sprint 49. It started on the 30th of January, and it's going to finish on the 11th of February. Okay. And it's very easily to see then that this team are delivering two features in that sprint. There's a spike UX or project X. There's a sign to Thomas. Okay. And then there's this login page they're going to be delivering. Okay. And then moving through the view, we're seeing a completely separate team here. So Team 2. And this is rolled up at the moment. So you're seeing just glance information of two features. Okay. And if we expand that again, then we see the work Team 2 are going to be delivering, which is this auto update and this web app security. So I noticed that the teams don't have to be running at the same cadence in this view here, right? So this is going to help synchronize and coordinate their deliveries? Exactly. That's right. A key principle we have is that teams, whilst it's beneficial to have them aligned on a sprint schedule, they don't have to in Azure context. They want to give them the autonomy to choose their own sprint schedule. So this way we're going to view them, all of the sprint schedules, against this normalized timeline. So it's easy to tell then when all of the work is going to be completed by a certain date. Gotcha. So these sprints, are these tied to iterations or areas of my team project? Exactly. That's right. Yeah, so you set up the iterations in your admin section and the teams will opt into those iterations. They say, so for example, Team 1 is working this sprint 49, 50, 51, Team 2 is on sprint A, B and C. And then they will assign the work into that iteration in the work item form. So let me show you an example. Sure. We can see in sprint 50, there's this build settings experience. It's actually assigned to me at the moment. And we can load that up. And then in the form, we're seeing then that the iteration is sprint 50. Gotcha. And then you can go into the form, make your edits and update in real time. Gotcha. And then that takes us on to another use for this view, which is all about being able to adapt in real time the plan of record. So for example, if this build settings experience and perhaps we're having a conversation that it's not required at that time or we don't have the resources to maybe deliver it in that time, then it's really easy in this view to just quickly pick it, drag it and drop it into the next sprint. Oh, I got you. And we drop it and there we are. We've rescheduled the view and it really is the now single version of the truth that all the teams can follow. Right. So if I were to go back to my, if I were to find this work item in any other view, the Kanban board, the backlog or maybe inside of my IDE, I would now see that this iteration has been changed to sprint 51. You've got it. Exactly that. And then if I were to make any of those changes to the iteration in any of those other places and then come back here, I would see that also reflected on this view. Always aligned. That's right. Gotcha. And you can see here then the card we have here, which is very similar to our Kanban cards. I'm just showing the title and the assignee here. And that's the important information I feel is relevant. But we can configure this as well. So for example, we can go into our settings experience and then tailor these cards to add additional fields whether it be tags we care about or perhaps the state that's being shown. So what we're trying to give is a very flexible canvas here for people to have the information that they care about most. Okay. And so at what level of item will show up on this, this delivery plan will bug show up here as well as user stories and product backlog items and I'm assuming tasks would not show up on a board like this one. That's right. Well, you can actually view tasks on the board if you like. We give the flexibility for the creator to choose. So if we go to this bottom team, Team 3, instead of seeing the features that you can see on a 2, now we're seeing stories and bugs. Interesting. And so from that perspective, it's easy to see then that you can see there's some dummy data here but there's the bug counts they have and then the user stories aside those. Again, with the same functionality to move back and forth. Fantastic. So do you guys actually use this on your own teams? Yeah, absolutely. So this is where it really spawned from. We have a large organization who's continually delivering to our hosted service every sprint and keeping all those teams aligned is challenging. And so the way we do it is we approach it in an agile way in terms of we have a prioritized backlog and we pull the work in per team. But yet we need to actually look ahead of ourselves to make sure that we're planning to resolve dependencies ahead of time so that we don't meet those challenges directly in sprint. We can be a little bit more scheduled about our work approach really. So internally we have something called a three sprint plan meeting where all of the teams who kind of related to each other will work together to build a delivery plan like this, talking about what they're going to deliver, what resources are going to be on that piece. Is there any emergent work that we weren't prepared for previously? And we used to do that in a one-note document, just very type of touch and the ironic thing was we had all the data in the system. So what we did, this is why we built this view. We can take the work item tracking data we have and the Kanban board flexibility and we really merge the two to kind of drive that meeting and make it very useful. I see, I see. So there's different views. Like for example, a task board is normally used by your developers, a Kanban board is normally used by your project manager or your product owner. Who do you see being the target audience for a delivery plan? Okay, so I think it's about cross team view. So program managers or product owners who care about multiple teams, I think that's important. Engineering leads who care about the work their team are going to deliver and perhaps are dependent on other teams. I think that view is going to be valuable as well. So we're hoping to make it broad for a lot of people in the organization and that's why we added the ability to customize the card. So for example, for me, the data you're seeing there about title of the card and assignee and state matters to me, but for someone else, maybe they want more of a list view. So something simple as just pressing the T shortcut key then removes all those fields and just makes it in a list view which is hopefully more digestible. Gotcha. And I've noticed there's a scale up in the right hand corner. What does adjusting the scale do for me? You've got it. So that actually, that will shorten and lengthen the length of time on the calendar. So you can see that we can zoom all the way out on all of a sudden we're seeing like a very high multi month view. Whereas if then teams were perhaps having one week iterations, then we're going to scale all the way in and we're going to be able to then view that the card details much closer. So that's the purpose of the scale though. Is there any ability on this screen? Cause I know we can do it on others but I don't see it offhand where I can add a new item to this particular screen. Not yet. No, that's a really great suggestion and that's part of the reason we're in public preview now. Okay. We believe we've brought an experience where you can view work across teams but we want to add dependency tracking into this. We want the ability to filter this more personally and add items and bring items from your backlog. And that's really where we're looking for a ton of feedback from our users. And we'd encourage people to go to user voice and give us these great suggestions because they really affect how we're going to keep enhancing this product. So what's the URL for user voice that someone would go to? Yeah, let me flick through this as well. So it's visualstudio.uservoice.com. And then if you place any of your ideas under delivery plans, then that's going to basically come through straight to me and we're going to get it on that backlog and deliver it. All right, perfect. Well, thank you so much for showing us this and I think a lot of people are going to be excited to be able to see across their teams because one of the things that you said that kind of jumped out at me and I get this a lot from customers is how can we coordinate our dependencies upon other people? Now I know that our visual student services team is kind of unique because I noticed you could run at different cadences, but we don't, right? That's right. All, what, there are 39 teams of us now? Yeah, actually run at a three week cadence, but it does not mean that one team doesn't still depend on another team. So how would that, like how would I be able or how are you envisioning to be able to determine that this item here depends on them completing some other item? Yeah, I think it's, the vision we have for it is probably something very simplistic, like we want to show that the dependency exists between two items and then I think we want to show something related to the health of the dependency. So not only that taking this example here, perhaps that the delivery service hooks feature is also dependent on the delivery of this security module, but also that the current scheduling here is a fairly healthy scheduling. They're both scheduled aside each other. It would be better if the dependent item, let's say you need to deliver the hooks first before you deliver the module. This would be a more healthy scheduling. Like we know this delivery hooks is going to be delivered at this point and then team D can pick it up. I see. And I think what we want to alert is that if the dependency is unhealthy, so if you know the dependent is scheduled beforehand, let's make that red, let's make it bold. Let's inform the user that they need to action something there. So that's our vision for dependencies. Well this is really exciting stuff. And I know a lot of customers have been asking for this. Not only internally, because we obviously needed it ourselves. I think it's really neat that we're a really good example of a highly functioning scrum team who delivers 39 different teams worth of work every three weeks like clockwork. And we needed this. And there's a lot of other companies out there who also need views like this. So thank you so much for coming to the show and sharing delivery plans with us. Great, thank you very much. Thank you so much for watching, guys.