![\"Image](\"https:\/\/devblogs.microsoft.com\/bharry\/wp-content\/uploads\/sites\/8\/2011\/06\/6862.image_thumb_236A05BD.png\")
<\/a><\/p>\nIronically, at the same time we were discussing this, we were deciding to adopt Scrum for our own feature team level development.\u00a0 We use more of a Microsoft practice for rolling that up through the organization.\u00a0 This was serendipitous because it would provide us a great opportunity to dogfood the tools and ensure we were building something our customers would love.<\/p>\n
Very early we decided to focus on a web based experience for our Agile project management tooling.\u00a0 A browser based solution makes the experience widely available to everyone on the team.\u00a0 At the same time, we felt projecting some of this directly into the Visual Studio and Eclipse development environments was also important.<\/p>\n
We broke down the basic Scrum project management cycle into the 3 highest priority activities:<\/p>\n
- \n
- Backlog management \u2013 collecting the list user stories (requirements) and prioritizing them.\u00a0 The backlog is one of the central theories in Scrum.<\/li>\n
- Sprint planning \u2013 choosing a set of user stories to implement in a sprint based on their estimated cost (story points) and the team\u2019s capacity (velocity).<\/li>\n
- Daily stand-up \u2013 reviewing the newly completed work, work in progress and newly started work along with any impediments.<\/li>\n<\/ul>\n
We also considered a few other things (like retrospectives, etc) but, after discussing it with many customers and Scrum professionals, concluded that the 3 I listed above were the key areas where new tooling would help the most and that other things could work fine with tooling we already have.<\/p>\n
For each of these experiences, we wanted to create a solution that was incredibly easy to use and low overhead \u2013 work the way I do and stay out of my way.\u00a0 We also recognized that if we were going to rely on our web experience this deeply we were going to have some significant work to do.\u00a0 We wanted to modernize the overall look and feel \u2013 we adopted the \u201cMetro\u201d style from Zune\/Windows Phone.\u00a0 We also needed to really work on performance.\u00a0 Web access, in 2010, relied too heavily on server round trips for user interactions.\u00a0 We wanted an experience that not only used Java Script to keep the vast majority of processing local, we wanted to make most places where server round trips are necessary (like saving a work item) asynchronous.<\/p>\n
As we started to adopt Scrum ourselves and design our Scrum solution, it quickly became clear that we were going to need to introduce the concept of \u201cTeam\u201d.\u00a0 Each of our feature teams have their own backlogs, sprints, etc.\u00a0 We needed a way to identify the teams, easily select them, define properties for them, report on them, etc.\u00a0 As such, for V.Next, team has evolved into one of our central elements of our web UI.\u00a0 You select what project and what team you are working on and then much of the data in the UI is filtered to show you exactly what is relevant for you.<\/p>\n
Product Backlog<\/h3>\n
In Scrum, the Product Backlog is kind \u201cthe one truth\u201d.\u00a0 It\u2019s the list of all work you have for a project.\u00a0 That work is expressed as user stories.\u00a0 You can think of a user story as a requirement.\u00a0 Some teams express their users stories in the form \u201cAs a <some type of user>, I can <do something> in order to <achieve some result>.\u00a0 User stories can be grouped together into what is called an \u201cEpic\u201d.\u00a0 This forms a hierarchy of requirements.\u00a0 The back log then orders these user stories from most important to least important \u2013 and you should implement them in that order.\u00a0 And any time something new comes up, it goes on the backlog.\u00a0 Of course, from time to time, you revisit your backlog and make sure it\u2019s still in the right order.<\/p>\n
Here\u2019s a screen shot of our product planning backlog.\u00a0 We\u2019re still working through the navigation model but let me call out some highlights.\u00a0 Looking at the upper left, you will see \u201cDevDiv\u201d.\u00a0 That\u2019s the name of the Team Project that Aaron is using (see his name on the upper right hand corner?).\u00a0 Next is \u201cAgile\u201d \u2013 that\u2019s the name of the team Aaron is on.\u00a0 Below that is a list of \u201chubs\u201d or areas of the product within the context that you\u2019ve set.\u00a0 What you see select here is the \u201cbacklogs\u201d hub.\u00a0 It allows you\nto see the entire product backlog or a past, current or future sprint.\u00a0 Within a backlog, you can easily add new user stories directly on the page and drag\/drop items around to set the priority.\u00a0 As you can see, you can also easily group them into a hierarchy.\u00a0 You can even drag an item over to a sprint on the left to automatically set the iteration path to a sprint.<\/p>\n
All in all, it makes for a very well tuned experience for managing a backlog.\u00a0 Simple, while at the same time, really fast to do all of the key backlog management activities.<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/bharry\/wp-content\/uploads\/sites\/8\/2011\/06\/2063.02ProductBacklog_thumb_2727AA8D.png\")
<\/a><\/p>\nSprint Planning<\/h3>\n
Once you\u2019ve got your backlog, it\u2019s time to plan a sprint.\u00a0 Simply click on a sprint on the left and the view switches to a sprint planning view.\u00a0 To plan a sprint, you need to choose a set of user stories and then break the user story down into tasks.\u00a0 As you do this, you need to iterate between estimated cost and capacity.\u00a0 Different teams choose to do this in different ways so we provide a number of options.\u00a0 You can, if you choose, just use story points to plan your sprint and skimp on task decomposition.\u00a0 Or you can decompose into tasks (in hours or any other unit you choose), assign tasks to a discipline (dev, test, etc) then do capacity planning by discipline.\u00a0 Or you can assign tasks to people and then do capacity planning by person.\u00a0 In this example, user stories have been broken down into tasks and assigned to people.\u00a0 The right side shows what work is assigned to each person relative to their capacity (red means over committed and green means under committed).\u00a0 The capacity bar above the user story list shows the overall sprint commitment vs capacity.<\/p>\n
On the gray bar above the user story list, you\u2019ll see \u201cBacklog\u201d and \u201cCapacity\u201d.\u00a0 These are views within the backlog hub.\u00a0 The capacity view allows you to configure how capacity is calculated (availability of people on the team, interruptions, etc).<\/p>\n
Lastly I\u2019ll point out that right next to \u201calm sprint 13\u201d (the name of the sprint), you see April 27 \u2013 May 17.\u00a0 Those are the date for the sprint\/iteration.\u00a0 That\u2019s another new foundational feature in TFS V.Next.\u00a0 We now have dates on iteration and those dates are used in several places through the product (for instance, reports can be set to display an iteration and they automatically pick up the dates).\u00a0 This is been a big customer request for YEARS and we\u2019ve now added it and incorporated into the Agile project management experience.<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/bharry\/wp-content\/uploads\/sites\/8\/2011\/06\/7041.10SprintPlanning_thumb_3053C001.png\")
<\/a><\/p>\nThe Daily Stand-Up<\/h3>\n
Once you\u2019ve planned a sprint, now you need to execute the sprint and, in Scrum, the primary tool for managing that is the daily stand up.\u00a0 In the daily stand up, team members gather together for as short a time period as possible (like 15 minutes) and review progress from the previous day, planned work for today and any impediments that are blocking progress.\u00a0 Some teams don\u2019t pre-assign work to people but rather use the daily stand up as the opportunity to pull work off the sprint backlog that they plan to do today.\u00a0 The tool of choice for the daily stand up is the \u201ctask board\u201d.\u00a0 It lists all of the user stories for the sprint and shows the state of the user story\/tasks \u2013 e.g. planned, in progress, complete.\u00a0 During the stand-up each member gets a few seconds to talk and makes any updates to the task board.\u00a0 In the early days of Scrum, the primary manifestation of the task board was a wall with sticky notes on it.\u00a0 As more and more teams adopted it \u2013 particularly distributed ones, electronic versions have become increasingly popular.<\/p>\n
Our new task board is shown below.\u00a0 It\u2019s a list of user stories on the left and a series of columns which represents the states of work (e.g. planned, in progress or finished).\u00a0 The cards in the grid represent tasks to implement the user story.\u00a0 You can easily see title of the task, who it is assigned to and the cost of the task.\u00a0 The task board is updated simply by dragging tasks from one column to another.<\/p>\n
On the upper right, you can see a burn down chart showing progress on the sprint.\u00a0 If you click on it, you get a bigger version, with trend lines, etc.\u00a0 You\u2019ll also notice that the grey bar has \u201cStories\u201d selected.\u00a0 If you select \u201cTeam Members\u201d, it pivots the work by person rather than by user story.<\/p>\n