 The new iteration status page is that here we can take a look at a board. The teams can stand around this iteration tracking board on a daily basis. They can look at the flow of cards throughout the sprint. They can dive deep if they want on discussion comments or tasks. So this is a great visual for teams to use to look at on a daily basis during their stand up and see how things are progressing. On the right hand side here, we have our iteration progress app. And this is showing a burn up of points on a daily basis. And if we switch over, if this is working. Anyway, it doesn't look like it's loading at the moment. But you can switch to different sorts of charts that help the team during their sprint. And also we can get a summary view of how the sprint is progressing. So this is actually a view into one of Raleigh's teams. They have two days remaining in their current sprint. They have accepted 85% of the total points they committed to. And they've got about two days left, so hopefully they'll finish on time. I'm going to reload this page momentarily. So in addition to the card view, we also can show a grid of items for the current sprint. So I personally prefer this view. I love looking at the board during the daily stand up with the entire team. But I like looking at the grid because it gives a little bit more details as to what stories we're working on, their tasks, etc. And so if I wanted to get more information about the task for a particular story, I can look at the task status column here. I just click on this icon to load the tasks. Maybe, maybe not. All right, seems like my internet access is not working great at the moment. So anyway, I could drill down into more details for each story that the team is working on during the sprint. So this isn't released yet. It will be released within the next month. But this is a new version of the iteration status page. So if you're already using Rally, this is going to be a great view for your teams to use on a daily basis. And I'll switch over to one of our other products, FloDoc. So this is something we're very excited about. FloDoc is essentially a team chat and team inbox. So on the right-hand side here, this is actually an area for a team to chat about items that they're working on. Just basically hold discussions on a daily basis. Anything related to do, or related with the work that they're doing. On the left-hand side, we can set up a whole bunch of different feeds to feed information into our inbox. So this could be emails, it could be Twitter feeds, it could be details about builds or production, etc. So if I take a look, I'm currently looking at the deploy tags. I'm looking at all the different deployments that our team, our FloDoc team and Helsinki is doing currently. We can drill down into each one, and for some reason this is not working. So the FloDoc app is great is because it gives the teams a central place to communicate. So all their communication, everything is happening in one location. They can just log in to FloDoc. They don't have to monitor email constantly. They get all their information right here in this one application. FloDoc has some great apps for some great mobile apps as well. So you can keep up with team activities on your phone. Yes, there is. So there's a number of integrations with Rally and other tools. And so you can just set up the Rally integration. You can talk about and reference items from within Rally in FloDoc, provide links to them, etc. And another thing I'd like to highlight is the configurability of Rally. And so using our dashboards and our custom apps, we can set up Rally to support pretty much whatever framework you're using. So the teams could use Scrum or Kanban at the organizational level. We could support things like Save for the scaled Agile framework. And so I'm going to demo a workspace we have here. Give me one moment. Okay, so we set up an instance of Rally to be modeled after the scaled Agile framework. As you can see here, we have the online store Inc as our master project. And below that, we have a number of Agile release trains. So the consumer program and the reseller program. And the view I'm showing you currently is actually a portfolio Kanban board. It's focused on epics. So this is a view that the great organization is going to look at to determine the status of work across all the teams, potentially across multiple Agile release trains at the same time. And so we can see here, we have items that are currently in the idea stage. Some are currently building business cases. Others are being prioritized, and then some others are being built. And for those items, those epics that are currently being built, we can actually get a view into the overall progress for those specific items. I have absolutely no idea what's going on here. But anyway, so we can dive deeper if we wanted to. And each of these items as they're being built, once they've been planned into our PSIs and see how the overall progress is going, even from the upper levels of the organization. Sorry, I'm going to switch browsers real quick. Okay, this seems to be working better. Okay, so another view you might use if you're following safe is a release train planning board. So this is a great example of another view you can set up in rally to help you plan your release train. So what we're looking here on the right hand side is our iteration planning board. So we could see multiple iterations for the release train for the upcoming PSI, we can drag and drop items into different sprints, create a blueprint for the PSI, we can look at the features that we've committed on the left hand side and the stories beneath them. You see the overall vision or theme for the PSI in the upper left hand corner. And so we can very quickly and easily plan our PSI right here on this one page. If you'd like to do weighted shortest job first calculations, we have an app for that as well. Here in the WSJF backlog, we can see all of our features. We can enter values in here for the time value, user value, job size, and then develop the overall score, etc. And so if we change any of these values, we can see that the score is updated on the right hand side. And so the score is something that's a custom field that's added to feature and through this app we can update it directly and this will provide the calculations for you. What's that? I'm sorry, can't hear you. The score? Yeah, so if you're using a weighted shortest job first, the score is the weighted score for that particular item based on all of these different factors. And so in this particular case, this score is based on this calculation here at the top. So it's user value, time value, plus risk reduction or opportunity enablement divided by the job size, which is essentially the size of that particular item. The lowest. Yeah, so the method they use is the same modified Fibonacci sequence to determine the job size. So it's not exactly story points because these aren't stories, but they use the same scale. And so the score is based using that same scale, but they're not actually story points because these aren't actually stories. Yeah, so features are typically managed at the program level, so product managers, et cetera. They're certainly going to take input from team members to figure out the job size. But at this level, we typically don't need the entire team to estimate something because it really hasn't reached them yet. So teams typically consume stories. They will take on features which will then be broken down into stories. But at this level, we'll have involvement from team members to create the job size. But most likely won't have been estimated by the entire team yet. Could you repeat that? I'm sorry. Sure. Yep, absolutely. So every single iteration, when you're performing planning, on the iteration planning board, so for each iteration for each team, you can set their velocity. And so here at the top, if you look, this is the team's velocity. So for iteration six, for PSI Q3 2013, their estimated velocity is 14 points, and they currently have 16 points worth of work scheduled. And so for each iteration, we can see whether or not it's overloaded. And then at an individual level, each team member is going to determine their capacity for each iteration as well, so we can make sure that individual team members aren't overloaded. It won't prevent you from doing so, but it will warn you that you are overloaded. Yes, so it has an indicator. And the same goes for the Kanban board. So if we look at the team Kanban board, if we go over our whip limits for any particular stage, it's going to notify you that we indeed have gone over our whip for that particular stage. So it's not a hard line. It will allow you to pull something else in, but it's going to make it very visible that you shouldn't. What other questions do you have? There's not currently. You mark work days, and that's going to drive all the capturing of metrics. So for example, if you mark Saturday or Sunday as not being work days, then we're not going to capture metrics for those days. But currently, there's no way to actually mark a holiday. Usually, just as part of planning, we discuss those and adjust accordingly. What other questions? Yep. Yeah, absolutely. So if you look at any of the dashboards in rally, there's actually a blocked work application. And it obeys the scoping here. So if we're looking at a single team, it's going to be only the blocked items for one particular team. If we move up the hierarchy, so we're looking across multiple teams at the same time, and then it would show all the blocked items. And so you could do this in a number of different ways. There's actually an existing blocked work app that we can add to the dashboard. Or I could very easily create a custom grid to get a little more control over the blocked items and what information I'd like to see. That took 10 seconds to create a blocked work app. And what's great about this is it obeys the overall scope. So if we're looking at a single team, we could just see the blocked items for one team, or we could look at all of the blocked items across the entire organization. I'm sorry, can you hear that? Yeah, so they won't reach the top. But this burn-up chart here, you could see that we've added the total scope line. So the goal here would be for those green bars to meet that black line by the end of the sprint. Yeah, so it should touch on the last day of the iteration. It should meet that. If you meet it a day early, that's great. Maybe you can pull in some more work and increase it the following day. That's the end of the time box. So if you guys have any more questions, our booth is just outside the ballroom. Feel free to stop by. We'll give you a more in-depth demo if you'd like.