Aaron Bjork

Agile Tip #9 – Motivation 2.0

Aaron Bjork MSFT — Mon, 07 Nov 2011 21:49:50 GMT

In last month’s column of Visual Studio Magazine we talked about Dan Pink’s book DRIVE: The Surprising Truth About What Motivates Us and how it relates to motivating Agile teams.

If you haven’t read Drive, I’d recommend you pick up a copy. For a quick teaser, watch this quick video that animates the main points in the book.

Agile Tip #8 – Planning and Learning

Aaron Bjork MSFT — Thu, 22 Sep 2011 15:00:00 GMT

My column in this month’s issue of Visual Studio Magazine talks about the value gained by Agile teams as they plan and learn.

An Agile Retrospective by Jeff Sutherland

Aaron Bjork MSFT — Tue, 02 Aug 2011 14:47:25 GMT

Jeff Sutherland, one of the founders of Scrum, recently wrote an artilce on MSDN titled "Ten Year Agile Retrospective: How We Can Improve In The Next Ten Years". The article captures key takeways (ten years later) from the original signatories of the Agile Manifesto. I'd highly recommend giving it a read.

VS 2010 and TFS 2010 How-To Videos

Aaron Bjork MSFT — Thu, 16 Jun 2011 15:00:00 GMT

Esther Fan posted a nice set of how-to videos yesterday focusing on VS 2010 and TFS 2010. Check them out here: http://blogs.msdn.com/b/vstsue/archive/2011/06/15/videos-about-visual-studio-alm-team-foundation-server-2010-on-msdn.aspx

Agile Tip #7 – Learning From the Past

Aaron Bjork MSFT — Thu, 26 May 2011 14:24:59 GMT

Retrospective meetings have been commonplace in software development teams for many years. Teams hold a meeting at the end of a project or milestone to discuss successes and failures. They use the data from that meeting to look for ways to create more success and less failure in future projects or milestones.

Agile teams in particular have embraced retrospectives as a way to drive continuous improvement into both teams and processes. As stated in one of the twelve principles behind the Agile Manifesto, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In this month's column, I dissect this principle and examine a few key elements of effective retrospectives. Read the full article at Visual Studio Magazine.

Agile Tip #6 – An Effective Daily Stand-up Meeting

Aaron Bjork MSFT — Fri, 22 Apr 2011 02:45:16 GMT

Yesterday, I published my first installment of a new monthly column I’ll be writing for Visual Studio Magazine. The column will focus on Agile practices and how to use them effectively on your teams. The first installment focuses on holding an effective daily stand-up meeting.

Professional Scrum with TFS 2010 Released!

Aaron Bjork MSFT — Fri, 22 Apr 2011 02:36:00 GMT

Today, Wrox released Professional Scrum with Team Foundation Server 2010! This is a new book I co-authored with Steve Resnick and Michael de la Maza. The book serves as a road map for using Scrum to organize teams and activities and shows you how to use Visual Studio Team Foundation Server (TFS) to execute a Scrum project with the Microsoft Visual Studio 1.0 process template. If you're new to TFS, or new to Scrum, I highly recommend picking up a copy. I authored 3 chapters in this book:

Chapter 3: Tracking What's Important in Team Foundation Server
Chapter 5: Work Items, Queries, and Reports
Chapter 11: Improving Scrum by Using Spikes

I'd love your feedback on the book!

Programmatically Reading Work Item Comments

Aaron Bjork MSFT — Mon, 10 Jan 2011 15:57:22 GMT

I recently ran across a few posts from people looking for samples on how to programmatically read user comments from TFS work items using the TFS API. It’s a simple operation, but it might not be clear at first unless you discover that you need to loop through the collection of Revisions of the work item in order to view those comments. Below is a quick code sample that demonstrates this behavior.

// get a reference to the team project collection
using (var prjCol = 
    TfsTeamProjectCollectionFactory.GetTeamProjectCollection(collectionUri))
{
    // get a reference to the work item tracking service
    var workItemStore = prjCol.GetService<WorkItemStore>();

    // grab work item 1460 and print out all associated
    // user comments.
    var workItem = workItemStore.GetWorkItem(1460);
    foreach (Revision r in workItem.Revisions)
    {
        // grab the history field
        Field f = r.Fields["History"];
        Console.WriteLine(f.Name + ": " + f.Value);
    }
}

For more code samples like this check out the Team Foundation Server 2010 SDK on the MSDN Code Gallery.

Using the Iteration Backlog Workbook on a CMMI Project

Aaron Bjork MSFT — Wed, 05 Jan 2011 21:35:27 GMT

The MSF Agile 5.0 process template that shipped with Team Foundation Server 2010 included an Excel workbook designed to help teams plan iterations of work. Because the workbook was aimed at Agile teams, it wasn’t included in the MSF CMMI 5.0 process template. However, that doesn’t mean it can’t be used by teams using the CMMI process template. Below are instructions on downloading and configuring the Iteration Backlog workbook for a team project started from the MSF CMMI 5.0 process template.

The first step is to open the Work Breakdown query in TFS and add the Iteration Path and Area Path fields to the results of this query. In this example, you will bind the workbook to the Work Breakdown query that ships with the CMMI template. In reality you could bind it to any tree query that includes a parent/child relationship between Requirements and Tasks and the appropriate fields. The workbook needs both the Area Path and Iteration Path fields so you need to add them to this query.

From Team Explorer, double-click the Work Breakdown query.
Click Edit Query from the query results menu.
In the results pane, click the Column Options button.
Add both the Area Path and Iteration Path fields to the selected columns list.

Click the Save Query button from

Next, you need to to download the MSF Agile 5.0 process template from your Team Foundation Server and grab a copy of the Iteration Backlog workbook.

In the Visual Studio Team Explorer, right click your Team Project Collection, then click Team Project Collection Settings, then click Process Template Manager.
In the Process Template Manager dialog, select the MSF for Agile Software Development v5.0 process template and click Download.
Save the process template to a local directory.

After saving the template, navigate to the \Windows SharePoint Services\Shared Documents\Project Management where you’ll find a copy of the Iteration Backlog workbook. Copy the Iteration Backlog workbook to a new location.

Finally, you need to bind the workbook to your CMMI team project.

Open the workbook.
Place your cursor in cell A1 of the Iteration Backlog worksheet.
Switch to the Team ribbon and click New List.
Select your Team Project and click Connect.
From the New List dialog, select the Work Breakdown query from your team project .

Save and close the workbook.
Save the workbook.
Close the workbook and re-open it.
After re-opening, the workbook will attach itself to your Analysis Services server and set values for a series of document properties use by the burndown worksheet.
Save the workbook again.

Your Iteration Backlog workbook is now connected to your team project and ready to use with your CMMI project.

Marking Tasks and Bugs as “Done” During a Check-in

Aaron Bjork MSFT — Fri, 17 Dec 2010 17:39:25 GMT

In recent weeks, a few different people have asked me how to modify the Scrum template such that a Task or Bug is marked as Done during a check-in. We left this out of the original state flow because we wanted the done state transition to be very intentional, but it’s a common practice and a very handy feature.

To change this behavior on an in-flight project you want to add the Microsoft.VSTS.Actions.Checkin action to the appropriate state transition in your work item definition. With the Scrum template, this would be on the In Progress –> Done transition for the Task work item, and the Committed –> Done transition for the Bug work item.

Below is a snippet of the In Progress –> Done transition on the Task work item after applying the changes.

<TRANSITION from="In Progress" to="Done">
  <ACTIONS>
    <ACTION value="Microsoft.VSTS.Actions.Checkin" />
  </ACTIONS>
  <REASONS>
    <DEFAULTREASON value="Work finished" />
  </REASONS>
</TRANSITION>

The easiest way to make these changes is to download and install the Team Foundation Server 2010 Power Tools which includes the Process Editor. Once you’ve done that, open Team Explorer and follow the steps below:

Select Process Editor –> Work Item Types –> Open WIT from Server from the Tools menu.

Select the project you want to modify.
Select the work item type that you want to modify (Task or Bug)
After the work item type definition loads, switch to the Workflow tab and double click the transition between In Progress –> Done.
Switch to the Actions tab, click New, and add the value “Microsoft.VSTS.Actions.Checkin” and click OK. The result will look like the screenshot below.

Save the new work item definition, and you’re all set.

The next time you make a check-in, you can choose to “Resolve” any Task that is in the In Progress state. The Task will be automatically moved to the Done state and associated with the changeset.

SP1 Beta and Project Server Integration Beta

Aaron Bjork MSFT — Tue, 07 Dec 2010 21:59:14 GMT

The Visual Studio and Team Foundation Server 2010 SP1 Beta was made available this morning. You can read about the details on Brian’s blog.

And, it’s exciting to see the announcement of the Visual Studio Team Foundation Server 2010 and Project Server Integration Pack beta. You can read more about the integration pack on Christophe Fiessinger's blog.

Autonomy, Mastery, Purpose

Aaron Bjork MSFT — Wed, 24 Nov 2010 00:06:14 GMT

While travelling in Berlin and Antwerp over the past couple of weeks I had a chance to talk about Daniel Pink’s book Drive with a variety of different people. I read his book for the first time a at the beginning of this year, and am now going through it again. I can’t say enough about this book… it really will change the way you think about what motivates people, and what motivates you. It’s phenomenal.

What I continue to find fascinating is how much overlap there is between Pink’s writing and the Agile movement. The Agile manifesto starts with “Individuals and interactions over processes and tools”. The thrust of Pink’s book is how every person does their best work when given autonomy, mastery, and purpose. I’m sure you can see the correlation.

If you haven’t read Drive, I’d recommend you pick up a copy. For a quick teaser, watch this quick video that animates the main points in the book.

TechEd Europe 2010 – Watch & Download

Aaron Bjork MSFT — Mon, 22 Nov 2010 23:20:17 GMT

Below are links to the slides and recordings from my sessions at TechEd Europe. If you’re interested, all the slides and videos from TechEd can be found here: http://www.msteched.com/2010/Europe

Lessons Learned through Dogfooding

http://www.msteched.com/2010/Europe/DPR202

This talk has two pieces. The first portion focuses on our internal process… how we manage work items, how we organize our teams, etc. The second part is a “Top 10” list I put together of lessons learned along the way. Some of the lessons are things that I’ve picked up, while others came from people around our team.

Agile Development with Visual Studio 2010 and Team Foundation Server 2010

http://www.msteched.com/2010/Europe/DEV310

In this talk, Peter Provost and I demo the lifecycle of a scrum project using Team Foundation Server 2010 and Visual Studio 2010. The demos include the Microsoft Visual Studio Scrum 1.0 process template and TDD with Visual Studio.

Project Server 2010 and Team Foundation Server 2010, Better Together

http://www.msteched.com/2010/Europe/OFS201

In this talk, Christophe Fiessinger and I introduce and demo the new Team Foundation Server and Project Server Integration Feature Pack.

TechEd Europe 2010 – Berlin!

Aaron Bjork MSFT — Thu, 21 Oct 2010 14:29:05 GMT

I’m off to Berlin next month to attend and present at TechEd Europe 2010. I’m giving four different talks over the course of the week:

Agile Development with Visual Studio 2010 and TFS 2010 with Peter Provost
An Agile Talk on Agility with Peter Provost
Visual Studio ALM: Lessons Learned through Dogfooding
Microsoft Project 2010 and Team Foundation Server 2010, Better Together with Christophe Fiessinger

If you’re there, swing by to say hi.

Urban Turtle 3.5

Aaron Bjork MSFT — Thu, 21 Oct 2010 14:09:18 GMT

The team over at Pyxis has just announced another release (3.5) of Urban Turtle – their Agile planning and tracking add-on for Team Foundation Server 2010.

Visual Studio Magazine Article

Aaron Bjork MSFT — Wed, 06 Oct 2010 21:21:38 GMT

I wrote an article for the October issue of Visual Studio Magazine on the new Microsoft Visual Studio 1.0 process template. It’s a basic walk through of how to get started using the Scrum template. Included in the article is a look at the following:

Building Your Product Backlog
Acceptance Criteria
Planning Your First Sprint
Tracking Your First Sprint
Understanding and Using Velocity

You can read the full article att: http://visualstudiomagazine.com/articles/2010/10/01/scrum-for-everyone.aspx

Microsoft Visual Studio Scrum 1.0 Videos

Aaron Bjork MSFT — Thu, 09 Sep 2010 13:42:23 GMT

Richard Hundhausen has released two webcasts featuring the Microsoft Visual Studio 1.0 process template on Channel 9. Both include Q&A at the end of the presentation. Check them out at:

http://channel9.msdn.com/posts/Charles_Sterling/Introducing-Visual-Studio-2010-Scrum-10/

http://channel9.msdn.com/posts/Charles_Sterling/Introducing-Visual-Studio-2010-Scrum-10-Part-II/

Microsoft Visual Studio Scrum 1.0 – Updated Sprint Burndown Report

Aaron Bjork MSFT — Sat, 31 Jul 2010 02:40:32 GMT

Last week we updated the new Microsoft Visual Studio Scrum 1.0 process template to include a fix for the Sprint Burndown report which was found to have a bug that caused an error when viewing the report in non-US locales. If you created projects before we made the fix (7/22/2010) you can follow the steps below to update your existing team projects with the updated Sprint Burndown report. Start by downloading and installing the updated template.

Right-click the reports node in Team Explorer and select Show Report Site.
Click Upload File and browse to the location on your local machine where the updated template is installed and select the Sprint Burndown report. If you didn’t change the defaults this folder is: C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\Process Template\Reports. Check the Overwrite item if it exists option and select Ok.
After the report is uploaded, click on it’s name to view the report. At this point you’ll see an error saying “The report server cannot process the report. The data source connection information has been deleted. (rsInvalidDataSourceReference)”.
Click the Properties tab on the top of the page, and then the Parameters tab on the left. At this point, you should see a screen similar to this one.

Uncheck the Prompt User option for the first parameter (ExplicitProject). Click Apply.
Next, click the Data Sources tab on the left side of the page. Under TFSReportsDS click Browse, and select Tfs2010ReportDS from the available options. Click OK.
Do the same under TfsOlapReportDS. Click Browse, and this time select Tfs2010OlapReportDS. Click OK.
Click Apply at the bottom of the page.
The final step is to set the caching property on the report. The default setting when you install TFS is 30 minutes. Click the Execution tab on the left and select Cache a temporary copy of the report. Expire copy of report after a number of minutes: 30.
Click Apply at the bottom of the page, and then click the View tab at the top of the screen.

At this point, you’re done. The new Sprint Burndown report has been uploaded to your Team Project and you’re ready to go.

Reporting Blog Posts and Articles

Aaron Bjork MSFT — Fri, 23 Jul 2010 14:27:13 GMT

For those in the business of modifying reports included in the MSF Agile, MSF CMMI, or Microsoft Visual Studio Scrum process templates, I’ve started collecting a set of blog posts and articles from colleagues, MVPs, and customers who have done a great job documenting some of the nuances and tricks around writing and modifying reporting in SQL Server Reporting Services. I plan to update this regularly with new links as I come across them.

Rename the State of a Work Item by Ewald Hofman

Add Additional States on a Report by Ewald Hofman

Creating and Customizing Reports by John Socha-Leialoha

Customizing MDX Report Parameters by John Socha-Leialoha

Customizing SQL Report Parameters by John Socha-Leialoha

Announcing Microsoft Visual Studio Scrum 1.0

Aaron Bjork MSFT — Mon, 19 Jul 2010 17:14:00 GMT

Today we’re releasing the first official version of our latest process template – Microsoft Visual Studio Scrum 1.0 (formerly known as Team Foundation Server Scrum v1.0 Beta). If you were following the beta, you know that this template was built from the ground up specifically for Scrum teams.

Visit the Visual Studio Gallery to download the template. John Bristowe has put together a great post on how to install the template. Below I’ve taken some time to describe what’s changed since the beta and also outlined a few of the key concepts/artifacts in the template.

Q: What’s changed since the beta?

A: There are no drastic changes between this release and the beta, but there are a few things worth mentioning. For those that were on the beta I’ll do my best to describe in detail why the changes were made.

The template has been renamed Microsoft Visual Studio Scrum 1.0.
Four new reports have been added to the template that focus on engineering metrics. The reports are almost identical to what shipped in MSF Agile 5.0 so I’ve linked the titles below to the guidance for those reports:
The new reports compliment the three existing reports that shipped with the Beta:

We’ve released a first cut at the process guidance for the template on MSDN. The content is still evolving, but the basics are in place and ready for consumption.
The Owned By (Microsoft.VSTS.Common.OwnedBy) field that existed on ALL work item types in the beta and which was used to assign ownership of work items has been removed and replaced with the Assigned To field (System.AssignedTo). We originally chose the Owned By field because in Scrum work is not “assigned”… and we wanted to use terminology and language that matched Scrum lingo. This was a tough one for us to revert, but in the end we found that NOT using the System.AssignedTo field (which is the default for every other work item) was going to provide more pain around integrating with other clients, tools, and partner solutions.
The DefaultTemplate build definition has been modified to NOT open bug work items on build failures. Why? Because the template expects that defects found that relate to work in the current sprint should be added to the Sprint Backlog as Tasks work items. This is done by adding new Task work items OR re-opening Task work items already marked as Done. Defects found that relate to work outside the current sprint are added to the Product Backlog as Bug work items. The philosophy here is that ALL new work needs to come to the team through the “front door” (the Product Backlog in this case). Because build failures likely relate to work in the current sprint we chose to change the behavior so as not to clutter up the Product Backlog with work for the team.
A new priority field has been added to the Impediment work item to allow teams to prioritize and order impediments more easily.
New transitions have been added to the Task work item to allow Tasks to move forward and backwards through the state lifecycle. You can now take a take a task from To Do –> In Progress –> Done, and also from Done –> In Progress –> To Do.
Both the Product Backlog Item and Bug work items have been modified such that you can now move a Product Backlog Item or Bug from the Removed state back to the New state. This was in response to feedback that “Product Owners often change their minds and we don’t want to have to create new work items each time that happens.”
A new Test Cases query was added to the Current Sprint folder.
And finally, a series of small text improvements were made to work item type reasons.

Q: Why did Microsoft decide to build a Scrum template? I thought MSF Agile 5.0 was Microsoft’s answer to Scrum?

A: The short answer here is… you told us that you wanted both of them. We have customers that want a generic Agile template that can be used to implement Scrum and other Agile methodologies. MSF Agile 5.0 does this very well. At the same time, we have many customers that want a very prescriptive Scrum template that matches strictly to the Scrum literature. Enter Microsoft Visual Studio Scrum 1.0.

Q: Did Microsoft work with Agile thought leaders when building this template?

Absolutely. We worked closely with a group of Scrum experts and trainers teaching the new Professional Scrum Developer Program including Ken Schwaber from http://www.scrum.org. It was very important to us that this template be recognized by the community (you) as a great option for Scrum teams. The Professional Scrum Developer Program is taught with Microsoft Visual Studio Scrum 1.0.

Q: How is the Sprint work item intended to be used?

A: The Sprint work item is intended to capture the sprint dates, sprint goal, and sprint retrospectives. Because TFS does not have a method for storing dates on iterations, we chose to create a Sprint work item that allows you to capture sprint dates and other sprint data directly in a work item. You can see in the screenshot that the Release 1\Sprint 1 work item is mapped directly to the Release 1\Sprint 1 iteration. When you create a new project with TFS Scrum v1.0 by default the project is provisioned with 24 sprint work items and 24 matching iterations.

Release 1: Sprint 1-6

Release 2: Sprint 1-6

Release 3: Sprint 1-6

Release 4: Sprint 1-6

With this model, you have both Sprint work items AND iterations… the trick is that you should have only one Sprint work item for each iteration that you create. For example, if you created a new iteration named Release 4\Sprint 7 you would want to create a new Sprint work item and assign it to Release 4\Sprint 7. The dates for this new Sprint would be entered directly on the Release 4\Sprint 7 Sprint work item.

The advantage to this approach is that when you’re working with reports in the template you don’t have to enter dates. Instead, you just select the Sprint(s) that you’re interested in viewing. The dates are read directly from the Sprint work item and used in the reports.

Q: What about the Iteration Backlog and Product Planning workbooks from the MSF Agile 5.0 process template?

A: At this time we have not ported over the Agile planning workbooks that shipped as a part of the MSF Agile 5.0 process template. We are still talking about brining over some version of the Iteration Backlog workbook at aid in Sprint planning, but it is not included in the 1.0 version of the template.

Q: Can I move data from an existing project into a new project build from Microsoft Visual Studio Scrum 1.0?

A: Yes. You can use the TFS Integration Platform to create a mapping between any existing team project and a new project built with this template.

MSF Agile 5.0 Guidance in Word Format

Aaron Bjork MSFT — Wed, 23 Jun 2010 14:54:01 GMT

Leonard Woody has produced a copy of the MSF Agile 5.0 process guidance in Word format if you’re interested in downloading. Great for printing and reading offline. Thanks Leonard!

How does MSF CMMI 4.2 compare to MSF CMMI 5.0?

Aaron Bjork MSFT — Fri, 11 Jun 2010 16:09:20 GMT

I’ve had a few people ask me about the key differences between the CMMI template shipped in TFS 2008 and how it compares to the new MSF CMMI 5.0 process template that shipped with TFS 2010 so I thought I’d detail some of the big differences. First off, it’s important to note that the changes in our Agile template were much more significant than the changes made to the CMMI template. The Agile template was largely overhauled to focus on core Agile principles and underwent some pretty significant changes with regards to work items and the overall process model. To read more about those changes see my post How does MSF Agile 4.2 compare to MSF Agile 5.0?

Back to CMMI… If you’re new to the CMMI template or new to CMMI altogether I’d strongly recommend reading Background to CMMI written by David Anderson who partnered with us on pieces of our process guidance. It gives a great introduction to what CMMI is, it’s purpose, and how it can be used. So, what’s changed?

Work Item Types

The work item types in MSF CMMI 5.0 are largely the same from MSF CMMI 4.2. There are two new work items types, Test Case and Shared Steps, which are related to the new testing features in VS 2010. See Creating and Managing Tests for more information on how to use these new work item types. But overall the fields and state transitions remain largely intact from MSF CMMI 4.2. We did do significant work on the layout of the forms to improve usability across all the work item types.

One small but important change is the elimination of the rule that cleared the Assigned To value when a work item was closed. In MSF CMMI 4.2 as a work item moved to the Closed state the Assigned To value was cleared. After listening to feedback that this rule made tracking who owned work after it was closed we made the decision to remove this rule on ALL work items.

Link Types

The first significant change is the inclusion of link types between work items. With the inclusion of link types in TFS 2010 the process model for the CMMI template has been updated to include a parent/child relationship between Requirements and Tasks, a tests/tested by link between Requirements and Test Cases, and an affects/affected by link between Change Requests and Requirements. These new link types make traceability easier and allow for rich querying and reporting.

Parent/child relationships also significantly improve the experiences of developing and organizing requirements into something the team can use. See Developing Requirements and Arranging Requirements into a Product Plan from the CMMI process guidance for more information.

Queries

All of the queries from MSF CMMI 4.2 have been carried forward to MSF CMMI 5.0 and new queries have been introduced to take advantage of link types and improvements in the overall process model. Those new queries include:

My Test Cases
Open Change Requests with Requirements
Proposed Requirements
Proposed Work Items
Requirements with Open Change Requests
Requirements without Test Cases
Untriaged Work Items
Test Tasks
Work Breakdown

And of course, the queries have been arranged into query folders for easy management and organization. The four query folders are: Change Management, Development and Testing, Planning and Tracking, and Troubleshooting. For more information on the MSF CMMI 5.0 team queries see the queries topic from the CMMI process guidance.

Reports

The reports in MSF CMMI 5.0 have been updated to provide a better experience from a usability perspective as well as project management perspective. The list of reports includes:

SharePoint Dashboards

And finally, the MSF CMMI 5.0 template includes a rich set of SharePoint dashboards that allow you to interact with work items directly from the dashboard as well easily create an publish reports directly to the dashboard. There are two versions of the dashboards – one built for the WSS and one built for MOSS. The MOSS dashboards are more advanced and heavily leverage Excel Services for custom reporting. Those dashboards include:

As always, let me know if you have any specific questions about the new template or how it differs from MSF CMMI 4.2. I’ve referenced quite a few topics above but I’d highly recommend you read through the entire set of process guidance here as it gives a great overview as well as specific guidance on how the template can be used.

Announcing Team Foundation Server Scrum v1.0 Beta

Aaron Bjork MSFT — Mon, 07 Jun 2010 16:13:00 GMT

7/19/2010 Update - this post applies to the beta release of this template. For details on the RTW please see this updated post.

- - - - - - - - - - - - - - - - - - - - - - -

Today , we’re announcing and releasing a brand new process template… Team Foundation Server Scrum v1.0 Beta. This is a new process template built from the ground up specifically for Scrum teams. So, why a new template? Quite simply, because you told us you wanted one. Scrum has become a dominant methodology in software development and you have told us that you want a process template aimed directly at Scrum teams.

I’ve written up a quick FAQ below to help with common questions. I’ll update this thread with additional questions and answers as they come in. We would love your feedback, so download the template and give it a shot. Click here to visit the Visual Studio Gallery where you can download the template.

Q: How does Team Foundation Server Scrum differ from MSF Agile v5.0?

A: TFS Scrum v1.0 is a Scrum process template. Nothing more, and nothing less. In contrast, MSF Agile v5.0 is an Agile process template that can be used to apply a variety of Agile practices/methodologies including Scrum. The biggest differences between the templates are found in the work item types, terminology, and state transitions.

TFS Scrum v1.0 WITs MSF Agile v5.0 WITs

Product Backlog Item User Story

Bug Bug

Task Task

Impediment Issue

Test Case Test Case

Shared Steps Shared Steps

Sprint

Below are screenshots of the Product Backlog Item, Bug, Task, and Impediment work items.

Q: Why did Microsoft decide to have both a Scrum and Agile template?

A: Because you told us you wanted both of them. We have many customers that want a generic Agile template that can be used to implement Scrum and other Agile methodologies. MSF Agile does this very well. At the same time, we have many customers that want a very prescriptive Scrum template that matches the terminology they read in the Scrum literature. Enter Team TFS Scrum v1.0.

Q: How is the state model different between Team Foundation Server Scrum differ from and MSF Agile v5.0?

A: MSF Agile 5.0 uses a fairly consistent state model across all work item types: Active –> Resolved –> Closed. TFS Scrum v1.0 uses a unique state model for each work item type that matches common Scrum terminology. For example, a Task work item in TFS Scrum v1.0 has the following state model: To Do –> In Progress –> Done.

Product Backlog Item and Bug Work Items

Task Work Item

Impediment Work Item

Q: What reports are included in TFS Scrum v1.0?

A: The first release of the template includes 3reports:

Release Burndown - Indicates how quickly the team is completing work and delivering Product Backlog Items.
Velocity - Indicates the amount of effort the team is completing in each sprint.
Sprint Burndown - Indicates the team's progress towards completing its work for a sprint

Q: Why are there only 3 reports in TFS Scrum v1.0?

A: We recognize that there are many more reports that could be helpful to a Scrum team. However, with this first release of the template we wanted to including what we felt were the necessary reports that a Scrum team needed to be successful.

Q: How is the Sprint work item intended to be used?

Release 1: Sprint 1-6

Release 2: Sprint 1-6

Release 3: Sprint 1-6

Release 4: Sprint 1-6

Q: Can I move my data from my existing project in TFS Scrum v1.0?

A: Yes. You can use the TFS Integration Platform to create a mapping between any existing team project an the new TFS Scrum v1.0 template.

Q: How does TFS Scrum v1.0 deal with Bugs?

A: Defects found that relate to work outside the current Sprint are added to the Product Backlog as Bug work items. Defects found that relate to work in the current Sprint are added by the team to the Sprint Backlog as Tasks work items. These defects represent unfinished work, and should be completed by the team during the Sprint.

Q: Where is the process guidance?

A: We’re writing the guidance for the work items right now, but we won’t have it ready until the beta is complete. You’ll notice that in the interim the process guidance directs you to Scrum.org. We worked closely with Ken Schwaber and others at Scrum.org in the creation of this template. If you’re new to Scrum I highly recommend you download and read the Scrum Guide.

Q: How long will the beta be?

A: As long as it needs to be (I know, that’s a cop-out answer, but it’s the truth). We don’t anticipate a long beta however, so if you’re got feedback, send it our way. :)

Urban Turtle with MSF Agile 5.0 and Visual Studio 2010

Aaron Bjork MSFT — Tue, 25 May 2010 13:49:55 GMT

Are you using sticky notes and index cards on a whiteboard or team wall? Well, if you are using the new MSF Agile 5.0 process template and Visual Studio 2010, you may want to have a look at Urban Turtle, a product from Pyxis, one of our VSIP partners. Urban Turtle is an intuitive Agile Project Management tool (plug-in) for Team Foundation Server 2010. It supports the MSF Agile 5.0 process template right out of the box, and since Urban Turtle works directly with TFS work items, it can be used in combination with the Agile Planning Workbooks or any other TFS tool you already use and love.

Urban Turtle will provide you with a task board to help the team track ongoing work and a planning board to simplify all your planning activities. And, if you have your own process template, or if you customize one of the out of the box template, Urban Turtle will still work for you because it can support virtually any process template through a simple xml mapping file.
Have a look and let them know what you think. I’m sure they’d love your feedback.

Agile Tip #5 – Learn to Love Acceptance Criteria

Aaron Bjork MSFT — Tue, 04 May 2010 15:07:00 GMT

Tip #5: Start to love and embrace acceptance criteria.

Ask 10 mature agile teams “How do you know when you’re ‘done done’?” and you’ll get the same answer from each one… get serious about writing acceptance criteria.

Acceptance criteria is the handshake between the product owner and the team on what “done done” really means. Until the acceptance criteria is met, the team isn’t done with the story. Period. However, the value of acceptance criteria only starts here. Acceptance criteria provides the stage for some of most meaningful conversations and interactions that can happen on an agile team.

On my own team we routinely have some of our best interactions as we start digging into the acceptance criteria for each story on our backlog. Inevitably we all start with our own ideas about what “done” means for a given story. However, as we begin to discuss the acceptance criteria presented by the product owner what ensues is a series of “ah-ha moments”. A shared understanding of the story begins to emerge. A comment one team member might elicit the following response from someone else… "Ah-ha, great point… I never thought of that.” Regardless of who is being enlightened, the power is in the fact that the product owner and the team are building together a shared understanding of what “done” means for each backlog item. And, this is happening before the team has written a single line of code… before any work has been done… before commitments have been made… and before the sprint has begun. By collaborating on acceptance criteria the team is minimizing risk and greatly increasing the chance of delivering successfully.

I don’t think it’s a coincidence that the first bullet in the Agile Manifesto states “… we have come to value individual and interactions over processes and tools”. Agile teams work together. And by working together, they create better software. Start learning to love acceptance criteria and see if your team isn’t more successful delivering software.

TFS Scrum v1.0 WITs	MSF Agile v5.0 WITs
Product Backlog Item	User Story
Bug	Bug
Task	Task
Impediment	Issue
Test Case	Test Case
Shared Steps	Shared Steps
Sprint