Previously, Sam Guckenheimer blogged about Scenarios, Value Props and Experiences and introducing them into Developer Division. Jeff Beehler followed up and talked in more details about the work items that we're currently using to manage the Team Foundation Server product.

In this post, I'll talk in more detail about what Value Propositions, Experiences and Features look like and how they are being used by the management team to plan and track the customer value provided in a release.

A bit of background: Historically, a number of groups at Microsoft tend to think in terms of "features" and breaking down those features into tasks and tracking that work.  Value Propositions and Experiences introduced a more all-up customer-centric view of things and a way to ensure during the planning phase that we are thinking about the customer in the right way and during the execution phase that we are delivering on that thinking.

Value Propositions

Value Propositions answer this question, "Unlike Visual Studio 2005, what if you could [insert value proposition here], would you use our product?" An example: "Unlike Visual Studio 2005, what if you could Trace work, conduct impact analysis and report status against requirements, would you use our product?"

Below you can see a Value Proposition that we're considering for a future release:

Notes:

• Value Propositions are fulfilled by Experiences and you can see that there are a set of Experiences related to this Value Prop.  Since TFS V1 doesn't have the notion of strong typed links (i.e. there is only one type of link between work items -- Related) the process and reports rely on everyone following the convention that Value Props are made up of Experiences.  We also use "exception management" to make sure that the convention is adhered to.  For example, we have a report that shows all the Value Props that aren't linked to an Experience.

Experiences

Experiences describe how we envision a customer would go through a path of the product.  For example, when someone shows a demo at a PDC, the focus on how a customer would use a part of the product and may touch on a number of features as go through that path.  Probably the more common term for Experience is "Scenario", but since that is so overloaded, we went with Experiences.  I like it as a way of communicating to management at the appropriate level of granularity.  Sometimes talking at the feature level is too much detail.

An example of an Experience:

Notes:

• An Experience is connected back up to its Value Proposition.
• An Experience breaks down into a set of features that represent the groups of work needed to make the Experience shine

Features

Features encapsulate all the important data that represents the work that a small team of program managers, developer and testers (we call it a "crew") to get a piece of product functionality done.    

A picture may help:

I'll be spending more time in a future post talking about feature tracking, but a couple of interesting notes:

• In the Planning tab, the feature captures a bunch of planning details around start and end iterations, estimates and start and end dates.
• The dependencies tab lists out all the other features that this feature depends on.  We built a custom control to manage dependencies because we didn't have a link type of link -- dependency.
• The crew tab captures the names of the team members working on this feature.
• The quality gates tab lists out all the requirements needed to be able to check in the feature from the feature branch into the product branch (e.g. passing static analysis and code coverage goals)
• The feature complete tab list out the sign-offs from various disciplines (PM, Dev, Test, UE, UX) in order to be able to check the feature in
• The custom tabs have a bunch of fields that allow the many different teams to tag features in the way they want to be able to query them later

So, now we have Value Props answering the question of what customer value -- those breakdown into Experiences -- representing how the customer value is perceived and then we have Features that represent the pieces of functionality that need to get done.  If you have all that and you've got people filling in the right data and maintaining it -- what can you get out of it?

The management team can look at a dashboard and get a bird-eye view of the progress made against delivering customer value:

Next week, I'll delve into the details of how we're tracking features and the kinds of things that features teams look at.

In the meantime, I'd love to hear about the kinds of work items schemas you have in place to track customer value!

Thanks,

-Siddharth