TFS 2010: MSF Agile vs. Visual Studio SCRUM 1.0 Smackdown -- Planning w/ Agile (Part III)

[アーティクル]
02/13/2011

In this final post for this series, I wanted to outline how Visual Studio SCRUM 1.0 is alike and differs when doing planning compared to MSF Agile v5.0. As I pointed out in my post last week, MSF Agile v5.0 ships as a process template with Team Foundation Server (TFS) 2010 and has a lot of out-of-box tools to help you plan, execute, and report on your progress. The release of Visual Studio SCRUM 1.0 recently has many wondering what they get “out-of-box” to do planning, execute, and report on progress. This is the goal of today’s post.

Visual Studio SCRUM – Understanding Your Planning & Backlog Process

The key thing to understand is that Visual Studio SCRUM 1.0 is a mere skeleton of the MSF Agile v5.0 process template beast. What I mean by this is that you will quickly learn that their isn’t any “multiple ways to do something” in SCRUM 1.0 as there is in MSF Agile. In MSF Agile, for example, you can choose to track your iteration progress using either Excel reports or use SQL Server Report Services (SSRS) reports. This isn’t the case when using Visual Studio SCRUM 1.0 – you have basically one way to do most things hence why I call it a skeleton compared to the more massive process template MSF Agile v5.0. (See below visual indicators)

You might quickly start to think that SCRUM 1.0 isn’t efficient because of this. Stop! This isn’t the case at all. The SCRUM 1.0 process template has many, many advantages over its counterpart MSF Agile. Let’s talk about them…

Managing your Backlog: Using Product Backlog Query

In Part I of this blog post, I shared that a great deal of the differences between the process templates are based on the terms used such as User Story versus Product Backlog Item. The backlog principle is the same anytime you are speaking about “Agile” and this is very important to understand.

To manage your backlog in Visual Studio SCRUM 1.0, the most efficient method is to utilize the Product Backlog query provided to you under Team Queries. You can choose to do this two ways – directly in Visual Studio (or Team Web Access) or using Microsoft Excel. The most efficient I’ve found is to utilize Excel and to do this you do the following -

Expand your project in Visual Studio
Click + to expand Team Queries
Right-click on Product Backlog and select Open in Microsoft Excel (Tree)

This will open the backlog with the columns you really need and allow you to efficiently add to the backlog.

The output will look like the following -

The one thing I do not like about this approach is the fact that it opens the Product Backlog with all the child links (e.g. Tree) for work that is currently being built. Because I wanted to focus right now only on the backlog, not do any de-composing of the work, I often recommend that you change the query type to help you focus on the task at hand – manage the backlog. This is only a suggestion on my part.

To change the query type, do the following-

NOTE: I will have you copy the original so that the shipped query isn’t altered. You can edit the query directly if you like.

Right-click on Product Backlog query, select Copy
Right-click on Team Queries, select Paste and provide a new name (I name it Product Backlog Only)
Rename the original query to say Product Backlog and Children
Open the query Product Backlog Only
In the toolbar, click Edit Query
In the Type of Query, change the query to Flat List (Default)
Click Save Query

This will ensure that you can easily add items to the backlog without dealing with the associated tasks. It is always smart to have a healthy and large backlog to drive great discussions in your Agile planning sessions.

Where’s the Product Backlog Workbook Excel Template like in MSF Agile v5?

This is one of the first things you will notice about Visual Studio SCRUM 1.0 – there are no supporting Excel workbooks with embedded macro’s. This might have many of you cheering and showing excitement because the workbooks do offer challenges sometimes and isn’t always clear of all bugs. With that said, there is a key piece of the workbooks you will find that is missing and really, really useful that we will point out later. Nonetheless, the product backlog iteration workbook along with the iteration backlog workbook are not available in SCRUM 1.0.

De-composing Work in Visual Studio SCRUM 1.0 and assigning to Sprints

This is one of the key things you will do anytime you are using Agile software development processes. You’ve got a healthy backlog and now it’s time to plan your work and break them down into releases and then create sprints.

Unlike MSF Agile v5.0 who has no concept of start time and end times for work, SCRUM 1.0 provides a new work item type called Sprints.

This sprint work item type focuses on a few key details as outlined in the table below -

Field	Field Purpose
Iteration	This field in Visual Studio SCRUM 1.0 actually is the name of the sprint. This field, when saved, will create a new sprint at the appropriate location in the Iteration tree viewed by right-clicking project –> Team Project Settings –> Areas and Iterations
Start Date	This is a date/time field that indicates when the sprint will start.
Finish Date	This is a date/time field that indicates when the sprint will end.
Sprint Goal	This is very important. If you have sprints that do not have goals, then your team will have difficulty judging their success during the Sprint Review. This is where you record the goals for the sprint.

SCRUM 1.0 is Iteration Un-friendly Out-of-Box – Clean it Up

A source of contention with me is that out-of-box, SCRUM 1.0 is noisy with their auto-created Sprints.

Microsoft is assuming that every project will have a release called Release 1, and that it will have sprints called Sprint 1. This continues all the way through Release 4. This causes you grief if you don’t call them by Release 1 so the first thing we do on any of our projects is delete any current sprints already created.

You can easily do this using the query “All Sprints” provided under Team Queries. Select all and delete.

Get started there first…

Sprint Work Item Type – The key difference between SCRUM 1.0 & MSF Agile v5

This work item type is the biggest fundamental difference between MSF Agile v5.0 and SCRUM 1.0. The ability to plan a true sprint and have it stored in in TFS is something that is vastly different than in MSF Agile. If you are familiar with MSF Agile, you should know that no sprint-related information is stored in TFS that is accessible via a WIT other than an iteration name. The only place that a start date and finish date are recorded are in the Iteration Backlog Excel workbook that is stored in SharePoint. Thus, you are challenged to accurately track your success (historical) without having a workbook per sprint that is stored in a document library. You could, also, use the SSRS report provided to track iteration progress called Burndown/Burn Rate though this again requires you to enter the dates yourself.

Visual Studio SCRUM 1.0 provides you this single work item type called Sprints.

De-composing PBI’s into Work in SCRUM 1.0

By default, after you’ve created your sprint you are ready to start adding the PBI’s to the sprint and then breaking those PBI’s into actionable work. This is where the rubber meets the road for Agile development teams.

Unfortunately, this is where it would be nice to have the Excel workbook called Iteration Backlog as there are two keys things to note that are missing from SCRUM 1.0 -

Interruptions – There is no ability to track interruptions that naturally occur in any team such as vacations, training, etc.
Capacity – In a perfect world, I love when I’m able to effectively have a feature team that is 1-1-1 meaning I have a full resource per discipline (PM, Dev, and Test) at 100% commitment to the feature team. This isn’t the case often. Because of this, often I have resources assigned to various feature teams and they are broken down like 20% on Feature Team A, 50% on Feature Team B, and 30% buffer. Scrum 1.0 doesn’t offer the ability to manage this in any capacity.

To effectively start adding work to the Sprint, you right-click on Sprint Backlog under the Current Sprint task and select Open in Microsoft Excel (Tree). You can also just use Visual Studio if you like but I’ve found it easier to use Excel.

That’s it. You now have a sprint, with work, and are ready to start tracking your progress.

My Dev’s out, Test is Behind, and I have a GM breathing down my back – Enter Sprint Burndown

This never happens. Developers always cost their tasks appropriately and test is never behind. What’s this about a micro-managing GM breathing down my neck? If this is true then you should just skip on to the Summary. For the rest of us who like to stay on top of things and run our projects effectively on a per-iteration basis, let’s talk & learn.

The single most efficient item that management likes to see are the following -

Show me completed work vs. remaining work (Burndown)
Show me progress against the Backlog

You will learn that Visual Studio SCRUM 1.0 does a great job of helping you keep up with number one but doesn’t do well at all in #2. This is an often interesting debate between John Socha as he & I debate the virtues of Story Points & release progress. You can easily determine the effort averages for a sprint using the release progress, or use velocity to track your team’s average story points accomplished in your sprint in SCRUM 1.0. The one thing you can’t do is accurately look at your progress at a user story level. This is where MSF Agile v5.0 was very nice and allowed you to run a report called User Stories Progress that tracked against recent work completed versus work completely done. In today’s post, I will not focus on this point at all and will save for another day.

The great thing about Visual Studio SCRUM 1.0 is it offers burndown reports right out of the box. At an instance, you can quickly look at the current sprint or any sprint taken place within the project. This is very nice!

As you can see, it is very easy to see that there is no confusing use of SQL or MDX to constrain the report to a particular iteration. Instead, Sprint is the foundation of the report all together. This report is easily identified under Reports and is key for folks to understand the progress of their iterations. The red arrow I point to will show all the sprints that are currently configured for your project.

The only other thing to note about tracking progress is that during Daily stand-ups for SCRUM 1.0 teams you will not track completed work. Instead, the only tracked information is remaining work when it comes to Tasks in Visual Studio SCRUM 1.0. This has at times become a source of frustration on our part as it broke other reports we had that did calculations between remaining versus completed. However, in the SCRUM 1.0 template you have work that is either in progress or To do and you track based on it and not on the hours involved as you do in MSF Agile v5.

As you can see, there are no complicated workbooks or difficult reports to edit to determine progress but instead a simple burndown report telling you how you are doing as a team.

Summary

It doesn’t go without saying – MSF Agile v5.0 & Visual Studio SCRUM 1.0 – that these two competitors are very much packing a heck of a punch. In the end, though, the Smackdown hopefully opened your eyes to the good parts of each competitor and also shed light on what you as a team will have to overcome if you choose one or the other. I often make opinions on my blog so I don’t feel bad for saying the two biggest pieces missing from each process templates are -

MSF Agile: You need the Sprint work item type badly! It is fundamental to any Agile team.
SCRUM 1.0: You need capacity planning & interruption support so that project owners can make real world decisions within each sprint.

Beyond that, a great deal of this smackdown has hopefully shared that the differences albeit at the surface look large are in fact just a slight shift in your thinking. Our engineering team, as of right now, is focused heavily on utilizing SCRUM 1.0 for our new projects. This, in our opinion, provides the best working framework for our heavily Agile software team.

I hope you’ve enjoyed this smackdown series!

Thanks,

-Chris

Comments

Anonymous
January 01, 2003
Hey Nick- Sorry for the delay in getting back to you. I was at a conference last week. With that said, let me see if I can explain what I meant... In Visual Studio SCRUM, the sprints are "work items" and are assigned an ID. Unless you have collection-level administrator privs, you will not be able to "delete" them as I indicated in my post (I'm going to fix this). Instead, the only mechanism to delete them is directly through iterations for that project. To do this, follow these steps-

Open the project in Visual Studio Team Explorer
Right-click on project, select Team Project Settings
Select Areas and Iterations...
Click Iterations Tab
Select the Release 1, Release 2, etc. and click the X for delete It will ask you if you want to move any "assigned" items to a parent node and I select the root. (there shouldn't be any if this is a new project) I just tested this on a PreProd server we have and verified it worked. Sorry for the mis-leading text there... I got a bit sloppy. :) Thanks, -Chris

Anonymous
January 01, 2003
I totally agree that the default template creating Release 1-4 with Sprint 1-6 is an annoyance. Could you explain what you mean when you said to use the All Sprints query and "Select all and delete"? Simply selecting all the results from the query and pressing the delete key doesn't do anything, and I can't find any UI elements that offer a "Delete" option. Thanks!
Anonymous
January 01, 2003
Hey Vamdisdar- I'm glad you found it useful and it helped you make the decision. I think that both really provide some coolness to them but it really depends on what you want. I can be followed via twitter @ chrad but I post a lot more personal things there than I do business related stuff (just a warning). But I do post technical stuff to it as well... Thanks, -Chris
Anonymous
January 01, 2003
Glad you posted that Nick and thanks for your answer Chris. It helped me too. Now to create some sprints and see how I go :-)
Anonymous
January 01, 2003
Chris, thank you for the wonderful finale of the smackdown. To me the benefit of having the Sprint WIT outweighs the lack of lacking some work books and capacity planning/interruption support. I have decided on SCRUM 1.0 and will soon start to implement it. Hopefull MS will come up with 2.0 that addresses the few missing pieces in the near future. Thanks again for your smackdown series that helped me make my decision faster. Will keep an eye on your blog from now on. Please publish your twitter account if you are announcing your posts on twitter.

次の方法で共有