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 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:
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:
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:
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!