Teams WIT Tools : Work Item Tracking

Work Item rules workaround: Saving the resolved reason

sunder — Wed, 01 Apr 2009 01:31:24 GMT

In our last post in this series, Gregg blogged about securing a work item type. Another question along these lines: “How can I save the resolved reason? I want to create metrics based on how bugs were resolved, but the value of the ‘Reason’ field is changed when the bug is closed”

Here’s the solution:

1. Add “Microsoft.VSTS.Common.ResolvedReason” field to the form definition

2. Add the following rules to the workflow transition from “Active” to “Resolved”

Here’s the end result; I am displaying the field in the Details tab of the Bug form:

This workaround works by copying the resolved reason when the bug is resolved off into the Resolved Reason field.

Sunder Raman

Program Manager, Team Foundation Server

[Cross-posted from http://blogs.msdn.com/sunder/]

Work Item Rules Workarounds: Secure creation of a work item type

Gregg Boer — Tue, 31 Mar 2009 22:44:09 GMT

In our last post in this series, Sunder blogged about Deactivating a work item type. Here’s another popular request: “Secure creation of a work item type”. For example, people say:

“Only my Testers can create bugs”
“Only my Business Analysts can create Requirements”

This is a legitimate request and we don’t have a good answer in Work Item Tracking, but do have AN answer.

First you add the following rules to the default transition.

<Transition from="" to="Active“ for=>
<REASONS>
    <DEFAULTREASON value="New" />
</REASONS>
...
</FIELDS>

   <FIELD refname="System.State">
      <READONLY not="[project]\Business Analysts" />
   </FIELD>
</FIELDS>
</Transition>

The group “[project]\Business Analysts” should then be populated with the users that can create this work item type.

Now if a user who is NOT in the group attempts to save a work item of that type, this is what he/she will see:

This is the approach we’ve found that works the best. But be aware of these issues:

It doesn’t prevent a non-approved user from creating a work item of that type, only from saving the work item of that type. Not the best experience.
The error message, of course, isn’t the best.

But it does do its job.

Someone who many have tried to solve this problem before, may be asking. Why aren’t we using transition security? Transition is the ability to allow only certain users to make a transition between work item states. Using this method, you would do this:

<TRANSITION from=“" to=“Active"

for="[project]\AllTesters" not="[project]\Business Analysts">

</TRANSITION>

The reason we didn’t like that method, is because of the error message you received:

“The field ‘State’ contains a value that is not in the list of supported values”

So … when choosing a method, we chose the one that displayed the error message closest to what we’d like to show.

That’s it!

Building lightweight dashboards using Excel

bamodio — Thu, 12 Feb 2009 23:38:00 GMT

TFS work items can provide a wealth of information that can be used for decision making and analysis, answering questions like:

Are we on track?
Is our bug debt growing or shrinking?
What is our incoming/fix/close rate?

and many others…

One way of keeping on top of the daily status is by building dashboards that help you summarize and clearly visualize all this information (this is particularly useful for driving triage and also for retrospective analysis).

Here is a sample dashboard that you can use to track your projects. It pulls data from a work item query to showcase some of these metrics, including bug counts, incoming/fix/close rates, bug backlogs, bug lifetimes, and more!

This sample Excel dashboard is designed to work with a project that uses the VSTS Agile Process for Software Development. Detailed usage instructions are available in the How to use this Dashboard sheet. Feel free to download it (with the disclaimer, “provided as is, you are responsible for its use”) and take it for a test drive, open it during status meetings, use it, and enhance it... We hope that it is valuable both as an example and as a starting point for leveraging the full power of work items.

Here is another post from Ameya that uses similar techniques (also has a video that might give you more details).

Feedback and comments always welcome... Enjoy!

Ben

New Power Tool for handling display name change in TFS

sunder — Thu, 17 Jul 2008 23:14:00 GMT

In an earlier post, Dan had posted the details on how a display name change in Windows or Active Directory doesn't automatically get updated in all the areas in TFS. We had a tool to help address this issue that was available only through our Customer Support.

Now, in our latest Power Tool release, we have added a new tool (TfsUsers) that helps administrators update TFS when user display names are updated in Active Directory. Brian gave a preview of the available Power Tools in his post. We now have released the latest set of July '08 Power tools.

There are two commands available on this new tool: computedelta and update. The first command, computedelta, helps generate a snapshot of the current state of valid users in TFS and identifying the fields that store person data . This snapshot is used as a baseline for computing the user display names that changed at a later point in time and automatically generating a mapping file. The mapping file is used as an input for the update command which updates the display names in TFS.

The latest Power Tool removes the manual mapping file generation that was previously needed and is also more easily available than our old tool, TfsWitDisplayNames. TfsUsers will help you till our next release where we are plan to make the updates transparent.

Please let us know what you think by emailing 'tfswitf at microsoft.com' or leaving a comment.

Sunder Raman

Program Manager, Team Foundation Server

How Microsoft/Dev Div uses TFS - Chapter 9 (Transparency in Reporting)

Gregg Boer — Mon, 09 Jun 2008 18:35:34 GMT

I apologize for not getting this post out sooner. I was not feeling well most of last week.

In a previous post, I talked about how we used TFS to implement the practice of Quality Gates. In this post, I'll talk some of the reports that were used to e track things from the top, CxO level, down to the individual features.

Here is our divisional dashboard:

You may remember in a previous post about implementing process, that we had value props, which traced to experiences, which traced to features. The above is a snapshot for the entire developer division on progress across all of them.

This top level report shows progress against all the Value Props. Value Propositions, as you may remember are divisional or departmental objectives, or pillars of the release. We had around 10 of these for the Orcas (VS 2008) release.

Clicking on a value prop (see the gray box above), will show you progress on experiences tied to that value prop:

Now you can see the progress of all the experiences and features associated with this value proposition. Drilling down to an Experience:

shows the progress on the features for that experience. Again. we can drill down on a feature:

and we see the Web View of the Feature record that I referred to in previous posts. With the Team System Web Access client, I don't see why this couldn't link to the actual Feature work item record itself.

These set of reports allows people at any level to view the status of the entire release. It also provides transparency, which is culture changing at all levels, but is for the best.

That's it for this post. I have two more posts in this series. One is to talk about the issues we ran into and another to answer the question: "Well, did it work?"

Thanks for listening!

How Microsoft/DevDiv uses TFS-Chapter 8 (Tracking Quality Gates)

Gregg Boer — Fri, 23 May 2008 20:55:04 GMT

In a previous post, I talked about how we tracked risks across multiple projects. In this post, I'll talk about how we tracked quality gates.

Let's ponder this for a moment. Let's say at the beginning of the Orcas development cycle, someone very high up in the organization makes statements like the following:

VS 2008 will have no performance regressions over VS 2005.
We will have 70% code coverage via automated test runs

Those are just two statements, but very big ones. How do you ensure that when a 3,000 person organization adds 100's of features over 2-3 years time that those statements will be true when its all done?

Our answer to that question was Quality Gates. In Orcas, we had 16 quality gates, ranging from simple ones like: "You will have a written spec" to measurable ones like "70% code coverage via automation".

On our Feature work item, we had an entire tab dedicated to Quality Gates.

Let's look at this a bit.

The first 4 quality gates were document based. That is, a document had to exist and be signed off to pass those quality gates.

The remaining quality gates were tracked by sign off and a status indicator.

Before a feature crew could mark a feature as complete, they had to ensure all the quality gates were met. To indicate they were done, they set the Quality Gate fields as met, not applicable, or exempted. The feature work item rules would not allow the State to be set to Complete unless this was done. If "Exception" was marked for any quality gate, then an "Exception Authorization" field became required, where you'd have to specify the executive manager who approved that exception.

This was effectively an electronic sign-off document. When you marked a Quality Gate as met, it was stored in the work item revision history that you made that change, effectively recording your signature.

That begs the question: How did you keep people from cheating and just signing them off. The answer is, we really didn't. Do I think that every single feature completed actually met the full spirit of every quality gate when marking the gate as met? No. Ensuring that would require a great deal of effort and time to follow up in detail with every single feature crew. This was an trust-based system. We trusted people to do the right thing, and I think for the most part, they did.

Another safety net was some of the quality gates were re-run on the main branch. For example, all localization testing (Quality Gate "Pseudo Loc" above), all performance testing, automated testing, was also run at the main branch on a regular basis. If someone checked in code that didn't meet those requirements, it showed up on the reports performed on the main branch.

For tracking the progress of quality gates across several feature crews, we used this report:

It was an Excel based report, that pulled in all the in-progress features, and used Excel 2007's conditional formatting to display yellow/green/red/black indicators for each quality gate. (Black meant, not started)

Like the other reports, each week, our project manager displayed the report and would ask questions like:

I noticed you are getting close to the end of your feature crew (the RI column in the report above), but you haven't started any of your quality gates. Care to explain?
You have marked some quality gates as Red. Why is that? Can we help?

So what we have here is not rocket science, nor is it mysterious. Just decide on the quality gates, make sure everyone is aware of them, and hold them accountable. However, without a system like TFS/Work Item Tracking to support this process, I do not see how we as an organization (or any organization for that matter) could be successful at implementing a process that is so broadly impacting and culture changing as quality gates was.

Wow, thanks for hanging in there to the end of this blog post! In the next post, I'll talk about some more reports we created to provide visibility from the top to bottom.

How Microsoft/DevDiv uses TFS-Chapter 7 (Tracking Risk)

Gregg Boer — Sat, 17 May 2008 00:44:44 GMT

In the previous post, I talked about tracking progress across multiple projects. Here I'll talk about how we tracked risks across multiple projects.

First, let's look at the Progress tab of the Feature record.

You'll see two fields related to risk. Risk Level is the standard traffic light indicator for risk. Green = We will meet the dates, Yellow = We are at risk, Red = We will miss the dates. The second field is descriptive text.

Every week, the project manager was asked to look at the dates published in the feature record, and determine if they felt they would still meet them, then set the Risk Level accordingly. Text was added in Risk Comments as needed.

This yielded this report:

This report is generated by Excel, which was bound to a query of all features where Risk Level <> Green. The color formatting was added by Excel.

So every week, any project who assessed themselves as non-green in the Risk area, was asked to just explain to the rest of the team why they were at risk and what they were doing (or needed to be done) to get back to green.

If the Risk was just reflecting a slip in the schedule, then the item would be Risk=Red for one week, everyone would understand that the schedule had slipped and why, the end date was updated, and the Risk was set back to Green.

You'll notice that the above risk report mentions "snow/ice storms" as a risk. In Seattle, we don't handle snow very well. You may chuckle about that, but everyone around here understood perfectly :-)

What about gaming the system?

You might ask, why would someone willingly show their project as Yellow or Red? Why wouldn't they just leave it as Green. Less heat, right?

I have two answers to that.

First, eventually, if a project was in trouble, people would have to slip their dates. If they all of sudden slipped their date by 4 weeks with no prior indication of risk, people would rightly ask the question: "Why didn't you know about this sooner?" or "If you did know about this, why didn't you let us know sooner?" That helps keep people honest.

Second, its about culture change. Setting your project Risk Level didn't always mean you were doing something wrong. Many times, the risk was out of your control. What is in your control, however, is communicating the status. People were held accountable for communication, not the project's risk. (Of course, if you were repeatedly slipping your dates, someone would talk to you!)

Next post, I'll talk about how we managed our quality gates using this system.

How Microsoft/DevDiv uses TFS - Chapter 6 (Addendum)

Gregg Boer — Wed, 14 May 2008 14:45:00 GMT

In my previous post, some people asked how we went about creating the report I talked about.

I asked the fellow who created this report internally. Here was his response, which I'm passing on to you. (Thanks Doug!)
NOTE: I've also attached the .RDL file he forwarded along.

being quote>

Here is the query which gets current values along with the value of completed & remaining work from some prior date (and the prior date is parameterized). The reason for the .[All] on the custom measures which get the work from N days ago is to deal with the scenarios where title or product unit or state etc had a different value on the prior date. In effect we are saying: give me the value of completed & remaining work from N days ago without regard to whether the value of those other fields match the filter we are applying to the current values (e.g. current state etc).

WITH

MEMBER [Measures].[ValueOfCompletedWorkAsOfNDaysAgo] AS

(

   [Measures].[Microsoft_VSTS_Scheduling_CompletedWork],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Group].[All],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Project].[All],

   [Work Item].[System_Title].[All],

   [Work Item].[System_State].[All],

   [Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[All],

STRTOMEMBER(@MDXDateForWorkCompletedSinceDate)

)

MEMBER [Measures].[ValueOfRemainingWorkAsOfNDaysAgo] AS

(

   [Measures].[Microsoft_VSTS_Scheduling_RemainingWork],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Group].[All],

   [Work Item].[Microsoft_DeveloperDivision_Classifications_Project].[All],

   [Work Item].[System_Title].[All],

   [Work Item].[System_State].[All],

   [Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[All],

STRTOMEMBER(@MDXDateForWorkCompletedSinceDate)

)

MEMBER [Measures].[FeatureEndDate] AS

EXTRACT(

NonEmpty(

        [Microsoft_DeveloperDivision_Features_DateEnd].[Date].[Date] *

        [Work Item].[System_Id].CurrentMember,

        [Measures].[Current Work Item Count]

    ),

    [Microsoft_DeveloperDivision_Features_DateEnd].[Date]

).Item(0).Member_Value

SELECT

Non Empty

{

   [Measures].[FeatureEndDate],

   [Measures].[Current Work Item Microsoft_VSTS_Scheduling_CompletedWork],

   [Measures].[Current Work Item Microsoft_VSTS_Scheduling_RemainingWork],

   [Measures].[ValueOfCompletedWorkAsOfNDaysAgo],

   [Measures].[ValueOfRemainingWorkAsOfNDaysAgo]

} ON COLUMNS,

NonEmpty(

STRTOSET(@WorkItemMicrosoftDeveloperDivisionClassificationsGroup, CONSTRAINED) *

STRTOSET(@WorkItemMicrosoftDeveloperDivisionClassificationsProject, CONSTRAINED) *

    [Work Item].[System_Id].[System_Id] *

    [Work Item].[Microsoft_DeveloperDivision_Features_RiskLevel].[Microsoft_DeveloperDivision_Features_RiskLevel] *

    [Work Item].[System_Title].[System_Title],

    [Measures].[Current Work Item Count]

) DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS

FROM [Current Work Item]

WHERE

(

   [Work Item].[System_WorkItemType].&[Orcas Feature],

STRTOSET(@WorkItemSystemState, CONSTRAINED)

)

<end quote

How Microsoft/DevDiv uses TFS - Chapter 6 (Tracking multiple projects)

Gregg Boer — Tue, 06 May 2008 17:50:31 GMT

In a previous post, I talked about the electronic status report. Basically, our status report was filling a number of fields on a work item.

Today, I'm going to show how our Program Manager in charge of managing all the projects for TFS used the information to track the progress of several projects at a time, using a series of reports.

But first, let me tell you about our process a bit. Every week we have a manager's meeting. That meeting's purpose is to track the health of the various projects that are going on.

The meeting is run by Jim Boyle, who is the Program Manager for our group. He is a superb Project Manager who has a lot of experience at holding people accountable.

Every week, Jim would display a report that looked like this. It showed all the in-flight projects (Feature Crews) going on.

Here's a bit of a description:

Green - The percentage of work completed, in compared to the entire project
Yellow - The percentage of work completed in the last reporting period, typically 1 week.
Red - The number of hours of work remaining.
You'll also note that the date the feature crew is scheduled to complete is included with the name of the feature crew.

OK, this report was projected on the screen. Then Jim would just start asking questions like:

Why did you not have any progress last week?
Why did you so little progress?
I noticed you have 1457 hours left, but your scheduled date is Jan 3, do you still feel like you can make that date?

Now Jim wasn't pounding his fist on the table and saying: "Why in the h*** are you not making more progress!". He just asked the question. The data presented showed a conflict and he just called it out.

Here were some of the answers given:

"I didn't get the data updated" - This became an unacceptable answer. There was a bit of a verbal spanking that happened, along with the reminder of how important it was to have visibility to this data. By the way, this accosting was done not by Jim, but by our Product Unit Manager (read: Brian Harry)

"We got pulled of on other emergencies last week" - This was a very acceptable answer. Although, in the meeting there was sometimes a redirection of priorities. In other words, management clarified that the emergency is not as important as the project. Either way, management had a much better idea of the status of the project.

"If everything goes well, and there are no complications or problems, we hope to get it done one time" - OK, this is obviously someone trying really hard to believe they can meet the original date. They are reluctant to slip the date because it makes them look bad. Basically the message to them was: We need a date that you have a high confidence of meeting. If you need to slip the date, its better for us to know now, rather than slipping it late.

You might have picked up that a culture change had to happen within our group. Transparency will force that upon you. In this culture of openness, management had to let go of "holding people to their original dates, no matter way" and those on the feature crew had to let go of "presenting the project status in the best possible light" or "hiding bad news". It was a learning process on both sides.

This post has gotten a little longer than I expected, so I'm going to stop this one. In future posts, I'll talk about how we tracked risk and quality gate status.

LINQ to WIQL

Gregg Boer — Wed, 30 Apr 2008 22:07:06 GMT

Someone showed me this post, and I thought I would pass it along.

How Microsoft/DevDiv uses TFS - Chapter 5 (Tracking Progress)

Gregg Boer — Tue, 29 Apr 2008 18:53:38 GMT

Before we talk about tracking progress, it might be useful to review the feature crew lifecycle as described in a previous post. The picture below will be a reference point for this post.

The picture below shows the "Progress" tab of our "Feature" work item type.

Basically, you are looking at my status report. As a person running a feature crew, I needed to fill this out once per week. I didn't have to send emails. No documents to created, I just updated the fields in the tab above. It was nice.

When the Developer Division decided to move forward with implementing the Feature Crew model as well as all the Quality Gates, we decided (wisely, I think) to not mandate how the feature teams themselves managed each one of their features.

So ... some did waterfall, with MS Project, some did SCRUM, some used Excel, some used sticky notes, some used just whiteboards. It really didn't matter to the division, as long as you updated your information in the tab above.

The Progress tab became a divisional standard for the minimal set of information you needed to communicate on a weekly basis.

You might think that looking at the tab above, that its too simple and too easy to game. The fact is, it turned out to be an extremely powerful tool for accountability. That will be described more in upcoming posts.

So let's talk about each one of the items above.

Key Dates - There were four key dates we tracked. The start and end date of the feature crew, and the two check-point dates. (See picture at top of this post)
IMPORTANT NOTE: A the start of the feature crew, the team needed to commit to a checkpoint 1 date, and estimate the checkpoint 2 and finish dates. At checkpoint 1, the team would commit to a checkpoint 2 date, and estimate the finish date. At checkpoint 2, they would commit to a finish date. I think that was a model that worked well.
Percentage complete - Basically remaining and completed work for the entire feature crew. While we did not mandate how people managed their feature crews, we did mandate they had to have a good enough handle on them to understand completed/remaining.
Risk Level - The first field is the standard traffic light indicator for risk. Green = We will meet the dates, Yellow = We are at risk, Red = We will miss the dates. The second field is descriptive text.
Additional dates that were interesting
Verbal prose describing the status of the feature crew.

That's about it for this post. In future posts, I'll show you how we used the above information to track the progress of multiple feature crews at a time, as well as some lessons we learned.

How Microsoft/DevDiv uses TFS - Chapter 4

Gregg Boer — Fri, 18 Apr 2008 19:37:00 GMT

In the previous posts, I spoke about how we used TFS to implement the process.

In this post, I'll talk about how we went about planning a release.

On the feature record, we had a "Planning" tab:

Zooming in a bit:

What we did is have people enter an estimated cost for each feature in the work item. Then we pulled them into a stack-ranking spreadsheet that looked like this:

This is a TFS-bound Excel spreadsheet with some formatting options. Note the following:

The ballpark estimates (and all the other data) are pulled directly from TFS. This was great, because all the estimates were entered separately, but could be pulled into a single place for planning
We stack-ranked all the features, top-to-bottom.
We added some logic to the spreadsheet to compare total cost with team capacity. Teams turned yellow if they used up more than 70% of their capacity, and turned red if they used up over 100%.

This gave us a very quick view of what could and could not be done, without a lot of work or schedule-crunching. It helped us determine where the cut-line was, and we played around by moving certain features up and down, to get a line we felt comfortable with. For example, some larger features were just moved down, simply because it allowed several smaller, key features to be above the cut-line.

Honestly, after a while, it felt like a video game. We called it the yellow/red game, because it was a trick to see how far we could push down the yellow and red! :-)

Next post: How we tracked progress

Rich text in work items

sunder — Thu, 10 Apr 2008 03:44:00 GMT

It is probably common knowledge by now that the history and html fields allow rich text input. Since there is no toolbar to edit rich text, I have seen users even compose text in editors like Microsoft Word and then paste it in the work item.

But looks like it is not very well known that the Visual Studio Formatting toolbar works for text in these fields! From the View menu, select Toolbars > Formatting to bring up the Formatting toolbar. When these controls are in context the toolbar is enabled letting you change font, font size, text color etc.

Here's a screenshot:

* I detached the Formatting toolbar from the top pane for illustration

We are working on adding a toolbar on the form itself for an upcoming release making it much more obvious that this functionality is available.

Sunder Raman

Program Manager, Team Foundation Server

How Microsoft/DevDiv uses TFS - Chapter 2 (Feature Crews)

Gregg Boer — Thu, 03 Apr 2008 19:03:26 GMT

One of the issues that Microsoft has to deal with on a very large scale is that while they are managing 1200 individual features, all of this works on a single code base. With all that activity going on, how do you maintain the quality of the code base, while allowing individual teams to focus on their features.

Our answer is feature crews. Its a model we adapted from the Microsoft Office team. It looks something like this:

When a feature crew (a team of people) is assigned to work on a feature, the lifecycle looks like this:

The feature crew creates a branch of the main source branch, to provide an isolated environment to work on their feature. They are isolated from any churn going on in the source branch, and they isolate everyone else from their work
As they work on the feature, there are two checkpoints. Checkpoints are when they present to management, to ensure management is in the loop of what is being done, and allows management to provide feedback on direction. Checkpoint #1 is about design. Here the feature crew presents how they plan to solve the problem.
Checkpoint #2 is about demoing the functionality. Here the feature crew presents what they actually did to solve the problem.
Once they've completed the feature, the feature crew integrates any changes that have taken place in the main source branch into their branch.
Before they check their changes back into the main source branch, all feature crews needed to meet a set of quality gates. Quality gates included things like "No performance regressions" and "70% code coverage through automated testing".
Once the feature crew had verified they had met the quality gates, they can then check their changes into the main source branch. The quality gates protected the main source branch, ensuring it was always in a near-releasable state.

NOTE: The goal was that a feature crew could complete within 4-6 weeks. (Didn't always happen, but the goal was to keep them short)

We had 16 different quality gates we needed to meet before a feature crew could be called "Done". Some of the meatier ones are below:

Quality Gates were the method we chose to ensure that 3,000+ people working on 700+ features on a code base of a bagillion lines of code (I really don't know how big it is, but you get the picture) ... that all that decentralized work could go on, yet maintain a consistent quality level overall.

While all the feature crews were working on their individual features, the entire division was managed to a set of iterations. I believe their were 14 iterations overall. The picture below depicts feature crews branch of the main branch, and integrating back into the main branch. Feature crews overlapped each other and overlapped iterations.

At the divisional level, we had Iteration Reviews, were all the teams would tell upper management what they expected to complete in the next iteration and what they actually completed in the prior iteration.

Next Chapter: Implementing the Process using TFS

How Microsoft/DevDiv uses TFS - Chapter 1 (Our Process)

Gregg Boer — Thu, 27 Mar 2008 17:51:32 GMT

Introduction

Many times, we have been asked: “How does Microsoft uses Team Foundation Server”.

This series of posts will answer that question (at least in part), by taking you through the processes the Developer Division went through to develop the Orcas release.

It’s important to keep in mind that everything I’m showing you is based on the Whidbey version of Team Foundation Server. (Duh … since we were developing Orcas J)

Chapter 1 – Our Process

Here is a picture that represents our process. This process was used for all of Orcas, not just TFS.

· Scenarios – Or more appropriately named, business objectives. These laid out the goals the division had for this release.

· Value Prop– The value from the customer perspective. Stated as “Why the customer would pay for this” All value props were traced to Scenarios.

· Experiences – The experience of the customer to realize the value. You can think of them as business level use cases, or scenarios, or epic stories.

· Features – The feature we needed to implement, so to enable the Experience to release the Value Props to meet the divisional goal. Features were the break-down of the work.

Another way to look at this is that Scenarios, Value Props, and Experience are all about planning the release, making sure we do the right thing. Features are about managing the work.

To provide perspective, here are the rough volumes of each that we dealt with in Orcas:

In future posts, I’ll show you how we managed all of this using TFS.

Next post: Our “Feature Crew” model.