***DRAFT***

Background

Our use of blueprints has evolved over the last few cycles to encompass new launchpad capabilities (workitems), and blueprints are generally how we communicate between the teams the status of certain features under development for a release (milestones, burndown charts, etc.)

To be able to improve automation further, we need to standardize on how we use them a bit more.

Specific areas of concern that have been raised:

• It's often hard to evaluate exactly when a blueprint has been completed.
• We sometimes have challenges with understanding the use cases for work.
• What the overall goal is for a blueprint is not always clear.
• Is there a user visible feature from this work that should be release noted.
• Endeavoring to bake QA into all work we do.

For simple features, not all teams follow the Wiki based specification and there are several variants of it.

Going forward the proposal is to use the blueprint template with the whiteboards and have some standard sections, to help with the push to automation and improving our quality.

Blueprint Template

Please use the following format with any blueprints accepted as work items for the release. Not all sections apply, but certain ones are mandatory.

Blueprint Summary

Rationale:

Mandatory.

One or two paragraph statement about why we are doing this blueprint.

Goal:

Mandatory.

Overall goal for the blueprint.

Template

[RATIONALE]
[GOAL]

Blueprint Whiteboard

User Stories:

User stories really help thrash our what the requirements are and why we are actually doing the work. They should try and encompass how you think the output of the blueprint will be used by real people.

There may of course be multiple stories for more complicated work.

Assumptions:

What assumptions are being made about the delivery of the blueprint.

Risks:

Document any possible known risk(s) that would block completion of the blueprint.

In Scope:

Document any areas that are specifically in-scope for this blueprint.

Out of Scope:

Document any areas that are specifically out of scope for this blueprint.

User Acceptance:

Mandatory (if code is being added to the release).

This is really about validating user stories; its helpful to think about these as high level processes. Then they can either be hand cranked by people who want to try stuff out, do manual QA, create automated tests, or covered by existing automated test cases. In either case the test plan should clearly communicate the new feature|update has been validated by the test plan and is therefore ship-able.

Release Note:

Mandatory (if user visible feature is being added to the release).

One or more suitable statements that could be included in the release note for the release associated with the blueprint.

Template

[USER STORIES]
[ASSUMPTIONS]
[RISKS]
[IN SCOPE]
[OUT OF SCOPE]
[USER ACCEPTANCE]
[RELEASE NOTE/BLOG]

Blueprint Work Items

Mandatory.

Here's where the actual work items for the blueprint should be listed and updated. When the key work items are marked "DONE" here, status of the blueprint should be updated to "Done" which should enable release notes to be published.

Syntax to use is:

[launchpad id] description of task: XXXX

where XXXX is one of "TODO", "DONE", "BLOCKED", or "POSTPONED".