Teams WIT Tools

New Power Tool for handling display name change in TFS

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)

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!

Using TFS, Excel, and Agile to deliver on time and on budget

We just finished our first real sprint using TFS, Excel, and the Agile process. One of the things that we had trouble doing in our last sprint, which wasn't really a sprint, but rather more of a marathon that seemed to never end, was shut down. We slipped our end date several times and each time was somewhat of a surprise for management, etc. This time around we decided to following a date driven Agile model and it worked out quite well. With TFS as the backbone of our project management and Excel (Iteration Backlog.xlsx that shipped with CTP12) as the front end, we were able to track daily/weekly progress easily. The Burndown chart and velocity chart helped us see if we were on track or not quickly and easily. We held daily stand ups to get face to face status and gut feel from everyone and then held weekly over view meetings to go over progress for the week. We were able to deliver what we said we would deliver when we said we were able to deliver and TFS, Excel and Agile were key in helping us do that.

TFS and Excel integration was a huge win for us. Although we struggled a bit at keeping our "Completed" and "Remaining" work up-to-date, after doing a post-mortem (See below for excerpts and custom chart from our post-mortem) on this sprint I believe the team now can really see the value of having accurate data to reflect back on to help us improve on the next sprint. Not only was there value in the post data analysis, but when the data was being kept up to date we could easily look at the burndown and velocity charts to see how the team was doing if we needed to make any course corrections or do some load balancing to keep on target. The iteration Backlog spreadsheet was able to sync with TFS and then did all the necessary calculations for us. We could see who was over or under utilized, our burndown, velocity, etc. The Iteration Backlog.xlsx spreadsheet which was shipped in Rosario CTP12 was a valuable tool for us.

There is a great webcast showing the use of TFS and the Product Backlog and Iteration Backlog spreadsheets in CTP12 at

http://teamsystemrocks.com/blogs/mickey_gousset/archive/2008/04/27/13967.aspx

To get CTP12 and play with the Iteration Backlog.xlsx go to http://www.microsoft.com/downloads/details.aspx?FamilyID=65D0E3BD-9DF3-421A-804F-8F01BD90F0B4&displaylang=en

Daily stand-ups were a great thing as well; possibly not too well received at first due to time and distraction, but in the end, I believe the team saw the benefit of these. Having daily stand ups really helped us make necessary course corrections, cut sub features, etc. in a timely manner so that we stayed on course to meet our end date which was a huge win for us. At first everyone was a little reluctant to do the daily standup due to time and disruption, but we grew to accept them more as the team saw my commitment to keep it to no more than 15 minutes and save the long design, or blocking issue discussions for after the stand up meeting so those not involved could go back and get focused on their tasks again with little disruption. The other advantage the team saw in having daily stand-ups was the value in face to face communication and the amount that we would learn from each other about issues being faced, or progress being made. On several occasions daily progress reports led to deeper discussions around what was really happening and what we needed to do keep on course. I highly recommend holding daily stand-ups.

Here's some excerpts from our post-mortem:

• What went well:
  • Adjusting Tasks weekly (add/remove, remaining work)
  • Communication between all disciplines
  • Load balanced well
  • Executed on plans

• What could have been improved
  • Time tracking near end of Feature Crew
  • Estimates could have been a little better - need more historical data
  • Velocity could have been better/consistent

Here's a quick chart I put together to somewhat show each individual cumulative work using TFS Data Warehouse. This chart shows the cumulative Completed Work for each individual by week. The ideal chart would be a perfectly equal rise/step each week to show the velocity was consistent and goals were being met without overtime or too little effort. The real key to this chart and any chart is the data entered. Thus it is critical that everyone enter their data at the very least weekly so more accurate analysis can be done at the end. Also note that with TFS and the Reporting feature these charts are easily produced. Here's a link to a blog entry by a reporting Dev to help you get started using TFS Reporting -

http://blogs.msdn.com/teams_wit_tools/archive/2007/04/30/understanding-the-tfs-cube.aspx

In conclusion, I would highly recommend using TFS, Excel integration, and the Agile process to help you deliver on time and on budget.

-Larry

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

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:

1. VS 2008 will have no performance regressions over VS 2005.
2. 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)

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)

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)

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.

TFS Send Mail for Team Explorer

As Brian Harry noted in his Blog, Orcas SP1 will have the ability to email a list of work items from either a query or the results view in Team Explorer.  This is a feature that will have everyday application.  I personally love it as a PM sending out email to the team which brings them to the work items they are interested in.

The Send Query Results to Mail feature can be accessed from the right click context menu and the View menu drop down if you have Outlook installed.  This feature this will allow you to send the entire query results easily with 2 clicks.

The Send Selection in Mail feature is also available from the right click context menu, the View menu drop down and the Tool Bar.  This feature takes whichever work items you have selected and sends them to the body of the email.

Both return a formatted list of work items to the email body either selected by the whole query or what was in the results view.  The work item ID with hyperlink is always in the first column.  The rest of the columns match the order and sort from the query.

By clicking on the work item ID, you can launch either the Work Item View or if configured the Team System Web Access client where you can edit the work item.

If you are interested in learning more about this feature check out the specification found here.

LINQ to WIQL

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

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

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.

1. 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.
2. 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.
3. 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.
4. Additional dates that were interesting
5. 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.

New Rosario specifications available

In an effort to gather your feedback very early on in the development process, we started publishing TFS specifications for the upcoming Rosario release. You might have already seen posts from Brian Harry announcing the availability.

We have published some new specifications in addition to the ones already out there:

• Query Folders - organizing team queries and my queries using in a folder hierarchy
• Enterprise Team Foundation Server Management - architectural changes to improve scale and manageability in enterprise environment

You can provide your feedback on the forum: http://forums.microsoft.com/MSDNWorkShop/ShowForum.aspx?ForumID=1981&SiteID=64

Thanks,

Sunder Raman

Program Manager, Team Foundation Server

TFS Sticky Buddy from Martin Hinshelwood

Martin has put out a cool tool on CodePlex: Sticky Buddy! 

It provides a WPF-based graphical view of work items by Area or Iteration. 

It's really easy to see the user stories that are active & resolved in the active Iteration (Iteration 1) and the user stories on the backlog:

And, you can hover over an item to get more information:

How Microsoft/DevDiv uses TFS - Chapter 4

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:

1. 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
2. We stack-ranked all the features, top-to-bottom.
3. 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

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

Michiel sent in a question about this blog post that I thought I would answer to everyone.

The question is: How do you create relationships between the work items? For example, Scenarios to Value Props, Value Props to Experiences, Experiences to Features.

For Scenarios to Value Props, we simply used an ALLOWEDVALUES list. That is, we define the Value Props work item type to have a field called "Scenario" and define a list of ALLOWEDVALUES. The ALLOWEDVALUES is tied to a GLOBALLIST, which is the list of Scenarios.

For all the other relationships, we use work item links. That is, we create a links between the Value Prop work item and the Experience work item. Those relationships just showed up in the links control on the work item form. You may notice that our MSF default work items have a tab called "Links" and that the work items hi-lighted in the previous post have the links displaying on the same tab as the description. Just wanted to point out this is entirely a form designer decision. You can place the links control wherever you wish.

A natural question would be: "How do you keep people from linking Value Props directly to Feature? How do you enforce the hierarchy?

The answer is, through exception reporting. A few people would be running reports that would point out any links that didn't belong and they would go clean them up. Not a pretty answer, but that's what we did.

Great question, Michiel! If other people have questions, please send them in via the blog email link.

PS: These are answers to the question, but I wouldn't call the good answers. A good answer would talk about typed links, hierarchical work items, etc... That kind of functionality is coming in Rosario.

How Microsoft/DevDiv uses TFS - Chapter 3 (Implementing the Process)

In previous posts and I talked about out processes. Today I'm going to introduce how we implemented our processes using TFS.

In review, our process looks something like this. Read this post, for more information on the process.

We used work items to tracking the above information.

The Value Proposition work item

Note the following:

1. The Scenarios are implemented by creating a Scenario field on the Value Prop work item, and setting ALLOWEDVALUES to the list of Scenarios. Since Scenarios (aka Pillars or Business Objectives) were small in number and fairly fixed as to what they were, this seemed appropriate.
2. The relationship between Value Props and Experiences were tracked by linking Value Prop work items to Experience work items.
3. The Value Prop has several fields to define the Value Prop, most notably the Description field to describe what the Value Prop was.

The Experience work item

Note the following

1. Experiences are linked up to Value Props
2. Experiences are linked down to Features

The Feature work item

Note the following:

1. Features are linked up to Experiences
2. The feature has many fields defining it. The Description field gives the curious browser a short description of the feature.
3. For more information, a person can go to the One Page spec on the feature. An URL is provided in the field.

What's next...

Will talk about how the planning process worked in Orcas.