Show and tell is a face-to-face meeting with the project team and stakeholders and must be scheduled at the end of each iteration. For example, show and tell is always on the tenth day of ten-day iteration. It is used to validate design and implementation decisions with the stakeholder. It also breaks down knowledge silos that may develop within a project team by providing a forum for review of the iteration results.

The agenda is to review any deliverable produced in the iteration and, where possible, have the stakeholder interact with the deliverable and validate the iteration results. This meeting gives the stakeholder an opportunity to change the direction of the project sooner rather than later in the process and is a key input into the planning game. Any stakeholder feedback that results in additional work should be captured in new story cards and estimated and planned in future iterations.

Roles /Responsibilities

• Project Manager
  • Confirms schedule and stakeholder attendance
  • Facilitates meetings
  • Determines need and assigns writing of new and revised story cards
• Project Team Member
  • Attends show and tells
  • Answers stakeholder questions
• Stakeholder
  • Attends regularly scheduled show and tells
  • Approves and/or represents approval of iteration release

Inputs

• BLUE  dotted story cards
• Issues and/or RED dotted story cards

Outputs

• New story cards
• Revised story cards
• Stakeholder feedback

Daily stand ups occur at a regular time and are meetings where project staff members quickly—within 30 seconds—communicate what they will be working on that day. They individually call out any issues that need to be resolved with other staff after the meeting. It is best practice to pass a token or icon to identify who is speaking and have the team physically stand next to the wall.

Stand ups are most effective in single project teams but can be used with multiple project teams that use a shared pool of resources. The format for reporting out is:

• Done—Be specific. For example: “I completed story card #37 and documented user goals.”
• Doing—Be specific. For example: “I am working on story card #40 and need help with designing the CSS.”
• To Do/Next—For example: “Next, I will finish story card #40.”

Colored stickers are used to inform project team members of individual progress on story cards. Stickers are placed on the story card, which is displayed on the wall, to inform team members of the following:

Standard Colors	Definition	Comment
YELLOW	In progress	—
GREEN	Done; ready for quality assurance	—
BLACK	Quality assurance in progress	—
BLUE	Done—Done; ready for production	—
RED	Work is stopped	—
ORANGE	Development complete and ready for unit testing	Reinforces the importance of unit testing (almost a code review in some cases) and is an answer to the lack of automated unit testing Strongly recommended until we are more mature in unit testing processes
WHITE	Started	Designates acknowledgement of story card assignment and collecting information prior to beginning workStrongly not recommended since the amount of time to prepare should be minimal and not important to track separately from YELLOW (In progress) status

Story cards are the lowest level of a work breakdown structure. Story cards are written so that the work is described from the perspective of business value; is testable, assignable, and estimated. A story card estimated at more than 64 hours must be further separated into multiple cards. Work represented on a story card should be independent of other cards (see plumb through) when feasible. Cards are captured electronically so they can be easily copied and shared. Story cards represent the mechanism for authorizing work (see the wall). All details should, as much as possible, be written on the card. It is appropriate, though, to note a reference to other project artifacts; such as the list of values, mock-ups, or storyboard.
                               
A story card must include the following:

• Project Name: Same as used in Planview
• Role: Type of person (business systems analyst, developer, performance support analyst, and so on) who does the work on the card
• Card Number: Unique identifier assigned by the card’s author; may be automatically assigned if using Team Foundation Server (TFS) or Click Commerce
  • Priority
    • Priority 1 is most important and is to be worked first
    • M-Reports: values 1 - 3
    • eResearch: values 1 through infinity
  • Rank
    • Subcategory of Priority used in TFS only
    • Values are 1 - 4
• Title: A brief summary of the task
• Status Dot: Colored sticker representing progress
• Pre-condition: Dependency on other story cards that need to be completed first
• Body: Full description of the work to be done; if using TFS, this information is stored directly there
• Author Initials: Person who composed the story card
• BSA Assigned: Contact who can answer questions about requirements described or referenced on the story card
• Date Written or Revised: Formatted as MM/DD/YYYY
• Planview Allocation: Specific task where effort is tracked for work on the story card
• Effort Estimate (hrs): Median estimate captured via the estimating game
• Actual Effort (hrs): Start-to-finish effort spent working on story card recorded in 30-minute increments; informs future estimating sessions for similar cards
• ETC: Estimated effort to complete if story card cannot be completed in the iteration