When we first started designing Team Foundation Server, one of our mantras was “Your process, our process or no process”.  What we meant by this was that TFS can play an important role in helping you automate your development process.  Many teams already have a well establish process and aren’t particularly interested in changing it.  TFS can be configured to fit with your process – whatever it is.  Many teams don’t have a well established process and would like to adopt some “best practices” and then evolve them – TFS can do that to, and we provide 3 process templates today you can adopt (Agile, Scrum and CMMI).  And some teams are less structured and pretty skeptical of the “P-word”.  They just want some good tools to help them get their job done and TFS can help there too.

In parallel to the evolution of TFS, the world of software development process has matured a great deal.  There’s way more energy and debate around process now than there was 10 years ago – and there are some emerging and established “winners”.  It’s clear that the Agile family of development practices have become very well established now.  Some of the practices that were highly touted in the early days of Agile (like pair programming) have drifted into niche practices and some (like unit testing) have become table stakes that almost every high performing development team has adopted.

We did some work in 2005 (unit testing, for example), 2008 (continuous integration) and 2010 (Agile workbooks, Scrum template, etc) that enabled teams to use TFS to automate their Agile practices.  However, we resisted building very tuned experiences because we were hanging a bit too tightly to process independence (remember – Your process, our process or no process.

As we began our planning for V.Next, it was clear that Agile had become mainstream (I have survey data that says 35% of development teams practice “Agile”).  And new processes are in the offing – Lean continues to gain momentum.  And, in fact, I see lots of people trying to combine the best of Lean and Agile together.  With the growing adoption of a well defined set of processes/practices, we decided that it was time for TFS to invest more in experiences optimized for those practices.  We still hold on to Your process, our process or no process but now we will build tooling optimized for well established practices.

One of the areas we chose to focus on was Scrum based tooling.  I have survey data that says about 84% of teams that say they practice Agile, practice Scrum as part of that.  That makes Scrum the most adopted Agile practice.  Here’s a chart that shows the adoption of methodologies by Agile teams:

Ironically, at the same time we were discussing this, we were deciding to adopt Scrum for our own feature team level development.  We use more of a Microsoft practice for rolling that up through the organization.  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.

Very early we decided to focus on a web based experience for our Agile project management tooling.  A browser based solution makes the experience widely available to everyone on the team.  At the same time, we felt projecting some of this directly into the Visual Studio and Eclipse development environments was also important.

We broke down the basic Scrum project management cycle into the 3 highest priority activities:

• Backlog management – collecting the list user stories (requirements) and prioritizing them.  The backlog is one of the central theories in Scrum.
• Sprint planning – choosing a set of user stories to implement in a sprint based on their estimated cost (story points) and the team’s capacity (velocity).
• Daily stand-up – reviewing the newly completed work, work in progress and newly started work along with any impediments.

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.

For each of these experiences, we wanted to create a solution that was incredibly easy to use and low overhead – work the way I do and stay out of my way.  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.  We wanted to modernize the overall look and feel – we adopted the “Metro” style from Zune/Windows Phone.  We also needed to really work on performance.  Web access, in 2010, relied too heavily on server round trips for user interactions.  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.

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 “Team”.  Each of our feature teams have their own backlogs, sprints, etc.  We needed a way to identify the teams, easily select them, define properties for them, report on them, etc.  As such, for V.Next, team has evolved into one of our central elements of our web UI.  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.

Product Backlog

In Scrum, the Product Backlog is kind “the one truth”.  It’s the list of all work you have for a project.  That work is expressed as user stories.  You can think of a user story as a requirement.  Some teams express their users stories in the form “As a <some type of user>, I can <do something> in order to <achieve some result>.  User stories can be grouped together into what is called an “Epic”.  This forms a hierarchy of requirements.  The back log then orders these user stories from most important to least important – and you should implement them in that order.  And any time something new comes up, it goes on the backlog.  Of course, from time to time, you revisit your backlog and make sure it’s still in the right order.

Here’s a screen shot of our product planning backlog.  We’re still working through the navigation model but let me call out some highlights.  Looking at the upper left, you will see “DevDiv”.  That’s the name of the Team Project that Aaron is using (see his name on the upper right hand corner?).  Next is “Agile” – that’s the name of the team Aaron is on.  Below that is a list of “hubs” or areas of the product within the context that you’ve set.  What you see select here is the “backlogs” hub.  It allows you to see the entire product backlog or a past, current or future sprint.  Within a backlog, you can easily add new user stories directly on the page and drag/drop items around to set the priority.  As you can see, you can also easily group them into a hierarchy.  You can even drag an item over to a sprint on the left to automatically set the iteration path to a sprint.

All in all, it makes for a very well tuned experience for managing a backlog.  Simple, while at the same time, really fast to do all of the key backlog management activities.

Sprint Planning

Once you’ve got your backlog, it’s time to plan a sprint.  Simply click on a sprint on the left and the view switches to a sprint planning view.  To plan a sprint, you need to choose a set of user stories and then break the user story down into tasks.  As you do this, you need to iterate between estimated cost and capacity.  Different teams choose to do this in different ways so we provide a number of options.  You can, if you choose, just use story points to plan your sprint and skimp on task decomposition.  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.  Or you can assign tasks to people and then do capacity planning by person.  In this example, user stories have been broken down into tasks and assigned to people.  The right side shows what work is assigned to each person relative to their capacity (red means over committed and green means under committed).  The capacity bar above the user story list shows the overall sprint commitment vs capacity.

On the gray bar above the user story list, you’ll see “Backlog” and “Capacity”.  These are views within the backlog hub.  The capacity view allows you to configure how capacity is calculated (availability of people on the team, interruptions, etc).

Lastly I’ll point out that right next to “alm sprint 13” (the name of the sprint), you see April 27 – May 17.  Those are the date for the sprint/iteration.  That’s another new foundational feature in TFS V.Next.  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).  This is been a big customer request for YEARS and we’ve now added it and incorporated into the Agile project management experience.

The Daily Stand-Up

Once you’ve planned a sprint, now you need to execute the sprint and, in Scrum, the primary tool for managing that is the daily stand up.  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.  Some teams don’t 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.  The tool of choice for the daily stand up is the “task board”.  It lists all of the user stories for the sprint and shows the state of the user story/tasks – e.g. planned, in progress, complete.  During the stand-up each member gets a few seconds to talk and makes any updates to the task board.  In the early days of Scrum, the primary manifestation of the task board was a wall with sticky notes on it.  As more and more teams adopted it – particularly distributed ones, electronic versions have become increasingly popular.

Our new task board is shown below.  It’s 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).  The cards in the grid represent tasks to implement the user story.  You can easily see title of the task, who it is assigned to and the cost of the task.  The task board is updated simply by dragging tasks from one column to another.

On the upper right, you can see a burn down chart showing progress on the sprint.  If you click on it, you get a bigger version, with trend lines, etc.  You’ll also notice that the grey bar has “Stories” selected.  If you select “Team Members”, it pivots the work by person rather than by user story.

We’ve been dogfooding this for the past several months and one of the things we quickly discovered was that, in the stand up, it was hard for the “next person in line” to easily find their tasks (even when pivoted by team member.  We recently added a new filter capability that makes it REALLY easy to focus in just on your work so you can make your updates and move to the next person quickly.

In the view below, you can see that it is filtered to Jon Tsao’s work (see right under the trend chart).  When Jon is selected, all the user stories in which he has no tasks are collapsed.  User stories in which Jon does have work are expanded.  And tasks that are assigned to Jon are shaded dark, whereas those not assigned to Jon are shaded lightly.  This makes it very easy f or Jon to focus on his work and update it.  Further, if Jon changes any task while filtered in this view (for example, he moves a task from “proposed” to “in progress”), the task is automatically assigned to him (if it isn’t already).  This speeds up the stand up even further.  If Jon needs to take a task from someone else or pull a task off the back log, he just drags it to a new cell and it’s automatically assigned to him – Very Cool!

Closing Thoughts

I feel really good about creating a great experience for people practicing Scrum.  I’ve only shown you a fraction of the capability that’s here but I hope it’s enough to wet your appetite.  As we entered planning for this next release, I was talking to my team a lot about focus on building polished solutions rather than just a platform on which finished solutions could be built.  I’m very proud of the work we’ve done to be very good at both.

In that vein, what you’ve seen here is a polished solution for Scrum.  However, if you don’t use Scrum exactly, it can still be very useful for you too.  Like everything else in TFS, it is very configurable.  You can configure what work item types you want to use.  You don’t like user stories?  That’s fine, change it.  You use multiple types of requirements?  That’s fine too – we support that.  You don’t like the Proposed, In Progress and Completed states?  That’s fine – that’s configurable too; define whatever states you want and we’ll manage them.  It’s a polished solution with a great deal of flexibility.

In the end, our Agile Project Management solution is a great way to manage your work, communicate priority and status.  One of the premier value propositions for this upcoming release is “Feedback” – in many forms.  As I talk more about V.Next in the coming months, I’ll show you how the work we are doing enables you to create excellent feedback cycles in your development process that helps you create a better result.  I view our Agile Project Management solution as providing an excellent approach to getting feedback on priorities and progress.  It provides some great visual views that the whole team can share and really easy ways to adjust your plans.

Our next release is going to be the best release yet and I can’t wait to share more of it with you…

Brian