Diff for "LaunchpadEnhancementProposalProcess"

Not logged in - Log In / Register

Differences between revisions 4 and 5
Revision 4 as of 2010-01-28 17:58:49
Size: 5265
Editor: jml
Comment:
Revision 5 as of 2010-01-28 18:50:29
Size: 5453
Editor: jml
Comment:
Deletions are marked like this. Additions are marked like this.
Line 104: Line 104:
=== Identify workflows ===

Any new feature will have a bunch of workflows in the UI. Get as many of these down as possible. Once you've got them down, start making mockups for them.

Launchpad Enhancement Proposal Process

  • Process Name: Launchpad Enhancement Proposal process

  • Process Owner: JonathanLange

  • Parent Process/Activity:

  • Supported Policy: None

Description

A way of proposing an enhancement to Launchpad, so that we're ReadyToCode as quickly as possible.

Rationale

Launchpad regularly develops new features. We'd like to make sure that these features are implemented well, and that they are what our users actually want.

This process is successful if it helps us make exactly what users want, with no wasted extra features and no crappy pain points in the new interfaces.

In particular, we want to have feature definitions that:

  • Produce requirements for use by Launchpad developers
  • Can inform QA
  • Make it easy for timely input from people who are interested

Triggers

This process is triggered when the Product Strategist schedules the implementation of a new feature onto the Launchpad RoadMap.

At this point, the feature is already expected to have a UserStory associated with it.

Roles

  • Product Strategist
  • Analyst
  • Stakeholders

The Product Strategist triggers this process and approves any output from it.

The Analyst is the author of any of the outputs. The Analyst can be any Launchpad developer or community member, but will normally be the Product Strategist or a Team Lead.

Inputs

The input should include a user story with a form like:

  • As a $PERSON
    I want $FEATURE
    so that $BENEFIT

There must also be a list of Stakeholders — people who are actually interested in the feature.

The input should also include a written reason as to why we are working on this feature right now, instead of other features that we could be doing.

Process

Collect the inputs

Make sure you have:

  • A list of Stakeholders
  • Some kind of UserStory — don't be too fussy here, whatever helps

  • A reason for doing this now

Create the blueprint

  1. Think of a HeadLine for the feature. It should be short and punchy. e.g. “Bug heat”

  2. Create a blueprint with the headline in the name
  3. Mark the Product Strategist as the approver
  4. Mark yourself as the drafter

Create the wiki page

  1. Make a page on https://dev.launchpad.net/, give it a similar name to the blueprint

  2. Consider using the LaunchpadEnhancementProposalTemplate

  3. Link it to the blueprint
  4. List the Stakeholders at the top
  5. Add the story
  6. Add the reasons for doing it now

Talk to someone

Talk to someone, anyone. Talk over the phone and make notes with something like Gobby, or just on the wiki page directly.

Good people to talk to include Stakeholders and the Product Strategist.

Start adding constraints

A constraint is some condition that the solution must satisfy. The constraints listed here should be:

  • specific, avoid “motherhood and apple pie” statements such as “feature must be awesome”

  • testable, it should be clear when the constraint is satisfied

But actually, the more the merrier. Get them down first, get them right later.

It's important to work with Stakeholders at this stage. Remember to ask “why” a million times over so that we get the right constraint down.

These constraints should not specify a solution.

Often, it's very helpful to describe what things are not included as part of the feature.

Jot down sub-features

Thinking about the problem will probably lead you to discover sub-features, smaller things that can be delivered independently and will add value while building up to reach the bigger story.

These sub-features can have their own feature document / blueprint thing, or they can go down in this document.

Either way, each sub-feature should go through a process very similar the one of the overall feature.

Identify workflows

Any new feature will have a bunch of workflows in the UI. Get as many of these down as possible. Once you've got them down, start making mockups for them.

Get it reviewed

Review the output with the Product Strategist.

This process is complete when we feel we have enough information to start designing a UI. Remember the process is iterative. It's expected that the actual constraints will be better understood as we start to design & implement.

Success criteria

Answer the following questions:

  • How will we know when it's done?
  • How will we know if it's done well?

Output

A Launchpad blueprint and a wiki page.

If not already, the LEP should be raised for discussion on the development mailing list.

Consider blogging or tweeting about it.

If the LEP is really, actually to be done, then make sure that it is linked from the RoadMap.

When doing user testing of this feature, use the LEP as a reference.

Notes

What is a requirement?

  • A constraint on a feature
  • Makes the "value" of the feature apparent
  • You can do an experiment that shows whether or not the requirement is met
  • A requirement is always for someone for some benefit
  • Are not set in stone
  • Do not specify a solution

TODO: Need to mark all existing blueprints as obsolete before using blueprints again

Comments

LaunchpadEnhancementProposalProcess (last edited 2011-07-28 22:46:44 by mbp)