Value Propositions, Experiences and Features revisited

sbhatia — Fri, 08 Feb 2008 08:06:59 GMT

A long time ago, I wrote a post on the internal project management processes we are using in Developer Division. It was all about Value Propositions, Experiences and Features. A year later, I'd like to revisit that and dive into the process we are using in Visual Studio Team System.

Not surprisingly, our process has changed (evolved?) since then. One big difference is that we are using a build of "Rosario" to manage our work vs. a build of TFS 2008. (In fact, the build we're using is similar to the "Rosario November CTP" -- so you can play with all the features that we're using.)

Planning List

We introduced the concept of a planning list where we can store a list of all the features we've been asked for and all features we've thought of. It's the list of everything we could build.

Here's an example of a Feature -- meant as a light-weight way to capture a request:

Then we group these features into "feature groups" and prioritize the features:

Then we stack all the "feature groups" against each other and proceed to execute in stack order.

The "feature groups" map up to Value Propositions which represent the rolled up value of a set of feature groups expressed in terms of our customers. For example: "Schedule and track Agile and CMMI project easily" is a value proposition in the system.

Execution List

The execution list represents everything we have built or are building. We introduced the concept of a Deliverable which represents a unit of functionality that a feature crew (a group of developers, testers and a program manager) produces. A deliverable is what goes through our quality gates (e.g. code coverage, pseudo-localization etc.) and it is what we track work on (remaining hours & completed hours).

Here is an example of a Deliverable -- heavier than a Feature in order to capture all the quality gate & progress data:

The quality gates that a Deliverable goes through:

And how we track the progress of a Deliverable:

We can break-down the Deliverable into the set of Tasks needed to complete it:

It is up to the feature crew to choose which tool to use to manage the Deliverables and Task breakdown. They could use MS Project or MS Excel or the Team Foundation Client or their own custom tool. All they need to make sure is that the remaining work and completed work on the Deliverable is filled out weekly.

And we use that information to review progress across deliverables on a weekly basis:

Though this report, we can see how much progress was made overall, how much progress was made last week and what is left to do.

Tying it all together

So, what is the relationship between features (the planning list) and the deliverables (the execution list)?

In our process, Deliverables produces one or more Features and we express that in the system by using a Produces/Produced By relationship.

In this way, as deliverables complete on the execution list one or more features are completed on the planning list and we can see how we are making progress against delivering customer value (value propositions):

Thanks,

-Siddharth

Internal TFS Usage: Tracking Customer Value

sbhatia — Mon, 15 Jan 2007 05:58:00 GMT

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

Teams WIT Tools : Internal Use

Value Propositions, Experiences and Features revisited

Internal TFS Usage: Tracking Customer Value