Value Propositions, Experiences and Features revisited

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

Comments

• Anonymous
  February 14, 2008
  Martin Kulov on Get latest does not work in TFS. The Teams WIT Tools Blog on Value Propositions, Experiences,...

• Anonymous
  March 03, 2008
  Hi, Could you please share this process template with us? I'm trying to make something very similar and i am having some hard times try to customize the existing process templates. Thanks, Cezar

• Anonymous
  March 24, 2008
  I'm in .. !!! I'm also interested in the WorkItem definition and the reports ... are you planning to publish them ??? or maybe include in some future version of any existing process guidance ?? Thanks in advance

• Anonymous
  June 08, 2008
  Kes veel ei tea, siis Workitem Tracking vahendite meeskond Visual Studio Team System -i arendusmeeskonnas