Agile Project Management in Visual Studio ALM V.Next

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 for 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…

Tags

Join the conversation

When you said "table stakes" you meant "ante." Ante is the minimum required for entry into the hand. table stakes means that you can't bet more than you currently have on the table (neither involuntarily – you can't be forced out of the hand if you don't have enough on the table, instead you go all in; nor involuntarily – you can't raise more than what you had on the table at the start of the hand.)

Hmm, thanks Steve, I never really looked into the actual meaning of the phrase. I've generally heard it used to mean "expected part" – kind of like ante, yes. It's good to know where the phrase actually comes from 🙂

Brian

6 years ago

Niel Zeeman

I hate it when you guys do this! 🙂 I'm still trying to convince some people to get onto 2010 and now you are showing us crumbs of the next version, which in all honesty, seems to have the makings of another great release..

I suppose this is how you keep guys like myself in business 🙂

Looking forward to hearing more!

One question – are you going to maintain/improve the extensibility aspect of tswa?

Niel, yes, we are working on extensibility of TWA. We have a new constraint that whatever we do for extensibility will need to work in a hosted environment where you can't run code in the shared hosted, environment. This means we'll be making some changes to our current WIT custom controls extensibility in web access. I've seen some demos of what you can do with the new web access extensibility and it would blow your mind. I'll blog about it in the not too distant future.

Will, yeah, clearly Lean/Kanban are becomming more popular. We're looking at how we could add the capability to make our new task board also work as a Kanban board.

Wonderful! I recommend having the ability to view design data into a LCD monitor

🙂

6 years ago

Philip Coupar

One part of the story commonly missing from managing stories is personas. Often the story creation starts from thinking abou tthe personas, telerik have done a nice job of allowing the persona to have a picture and a story about them then be auto linked into storied merely by using the personas name.

Linkage to personas also allows better impact analysis or prioritisation, as a sprint could be selected from those imacting one persona.

This is somethign that is missing from the current agile template and would be great to see in V.Next

I've read it and I've exchanged some emails wih Ken about it. Let me start by saying that I respect Ken greatly. He's contributed a great deal to the industry.

Without trying to be too presumptuous about Ken's issues, I understand the two main ones to be this:

1) In Scrum you don't assign tasks ahead of time – you pull them off the sprint backlog on demand.

2) You don't cost and capacity plan your sprint tasks in Scrum.

First let me say, that the Agile Project Management feature supports rigorous Scrum 100% (and if there's anything we've missed, we'll fix it). You don't have to assign the tasks ahead of time and you don't have to do capacity planning. However, in talking with customers we've found a wide range of practices. We've built a tool that is lightweight and enables a number of different work styles.

In speaking with Ken, he acknowledges that even teams on the journey to Scrum go through stages where they want/need these features. His issue is not so much that we made it possible but rather that, in my post, I was not clear that some of these features would not be part of the ultimate destination for many teams – a rigorous Scrum process.

Ken is very particular about what gets attributed to Scrum – as he spends his life trying to help people understand how to be successful with Scrum. My aim in this post was to describe the tool and it's capabilities and I wasn't that focused on being crisp on the Scrum process.

Brian

6 years ago

simon geering

Have MS looked at DSDM (http://www.dsdm.org/) this is widely used in Europe but doesn't seem to be so well know in the US.

6 years ago

Yuval Gatenio

Does a new Process Template is going to be released or the additions is on the operating side (IDE)?

I'm currently working with TFS 2010 and have a project with Agile 5.0, can i work with it and prepare the relevant work items to be used with V.Next?

Yes, it is. Any early version of it was release in our preview in September. A more recent version is available on our online service http://tfspreview.com. And we'll be shipping a Beta in the next month or so.

Brian

5 years ago

Manny Siddiqui

When will TFS in the cloud (www.tfspreview.com) will be going live? We are embarking upon a new project and I was wondering if we could use the TFS in the cloud. Any insights will be helpful for us to plan.

"Live" is a bit of a relative question. It's "Live" now. Tons of people are using it for production projects today. In my opinion, there's nothing to worry about with respect to quality of service, confidence that your data will be maintained, etc. The only things that are limits are – we haven't gotten all th features enabled that we want to yet and we haven't gotten a billing system in place. There's enough features up now to do an aweful lot so that won't affect most people. The lack of billing is a concern for some – people aren't sure what it is going to cost. The truth is we don't know yet. We've said several things though: 1) There will be a free level of use. 2) We intend to competetively price it. 3) If you don't like the pricing when we announce it, we'll provide a grace period and tooling to migrate your project onto an on-premise server or to another hosting service.

Brian

2 years ago

Rob

"Some teams don’t pre-assign work to people"

I'll assume this is a typo 🙂 Should be: "Scrum teams don’t pre-assign work to people"