Considerations for Value Streams

These lists of considerations are useful reminders for DAD teams to help them consider the practices of DAD and agile/lean during the various phases of the life cycles.

Use these lists of considerations as starting points. You should adapt them to fit your own local context and terminology.

Many of these considerations are most appropriate for software development teams. You may be able to adapt them to other types of contexts.

Considerations for Construction Phase

Iteration Planning

Activity	Description
Roles	Product owner and architect owner assigned
Team	Team identified with all of the needed roles: dedicated to the release, funded, and colocated as much as possible. The team is staffed with all of the needed roles, funded dedicated to the release, and colocated as much as possible. Team has received required training: Lean-Agile software development, Test-Driven Development, Engineering practices
Environment	Review and define workflow. Review and define visual board. Review policies for stories. Establish logistics for meetings, locations, times, frequency, participants. Tools for testing, coding, integrating, building are selected and installed. Established logistics for daily coordination meeting (time, location, conference call information, website). Agreed to the ground rules for team life. Organized (and clean up) the team work space: physical, communication, collaboration. Set up the team’s project board. Established the test and build environment.
Vision	Release vision statement is prepared. The team understands and agrees to the vision, drivers, and expected outcomes for the release.
Backlog	MBIs introduced and reviewed with team. Refine description, scope, validation, and done criteria. Identify risks, issues, dependencies, uncertainties, and known impediments. Rank, prioritize, and represent these with stories.
Architecture	Review and define the high level architecture and design. Architectural goals and approach identified, visible. Dependencies and risks Identified, visible. Conceptual design completed.
Technology components	Identify technology components. Input technology features and/or stories into team backlogs.
Feature sequence	Finalize feature sequence by business value and technical dependencies.
Iteration backlog (if iterative life cycle)	Iteration length is set. Iteration backlog established, populated, and visible. Stories are assigned to the first few iterations Input items into appropriate tools. Team has committed to iteration 1 plan.
Story estimation	Review and define complexity factors that will be used for relative sizing in story points. Stories decomposed and right-sized: Analysis stories if needed User stories for first feature Validation criteria for stories are understood Stories are estimated for first few iterations’ work.
Continuous improvement	Intentionally incorporate lessons learned from previous releases.
Testing agreements	Definition of Done established and documented (Unit, Integration, Acceptance). Testing approach (Unit, Integration, and Acceptance) is committed to and visible.
Reporting and metrics	Book of Work program backlog. Top-line story points. Feature burn-up.
Artifacts	Identify product documentation that must be maintained.

Iteration Planning Meeting

Activity	Description
Vision	The team understands and agrees to the iteration vision. All members of the team have a common interpretation of the various terms used in the vision statement.
Learning from the past	For the kind of work we are going to do in this iteration, are there lessons learned or good practices that we incorporate from anyone on this team, on other teams in the organization, or in the literature? Invite a “Second Set of Eyes” from outside to think through the plan.
Story estimation for iteration	Initial estimate of story points for iteration. Stories decomposed and right-sized. Validation criteria for stories are understood. Stories are estimated for first few iterations’ work.
Dependencies and risks	Dependencies and risks identified as stories. Impediments identified, posted on team board, assigned.
Iteration backlog	Stories are assigned to the iteration backlog. Tasks are identified for the stories in the iteration backlog. Team has committed to iteration plan.
Commitments	Commit to demonstrating the product to key stakeholders at the end of the iteration. Commit to conducting a retrospection at the end of the iteration. Commit to conducting retrospectives as appropriate during the iteration.
Testing agreements	Definition of Done established and documented (unit, integration, acceptance).
Team	The team is staffed with all of the needed roles, dedicated to the release, and colocated as much as possible. Team has received required training in process, testing, and engineering practices. Artifacts and deliverables determined (and visible).
Team environment	Tools for testing, coding, integrating, building selected and installed. Established logistics for daily coordination (time, location, conference call information, portal, etc.). Agreed to the ground rules for team life. Organized (and clean up) the team work space: physical, communication, collaboration. Set up the team’s project board. Established the test and build environment.

Iteration Execution

Activity	Description
Input tests / code until tests pass	Unit test has been completed and documented. Defects clearly defined, resolved and tested.
Run functional tests	Functional tests have been completed, documented. Defects clearly defined, resolved, and tested.
Run user tests	User tests have been completed, documented. Defects clearly defined, resolved, and tested.
Update business processes and conduct training	All impacted business processes have been assessed. Appropriate changes have been made. Training has been developed and executed. Participants have been certified.
Product owner / analyst acceptance	Product owner or analyst has formally validated that the story has been completed and is ready to be promoted to production to support the MBI.

Product Demonstration and Review

Rule	Description
Demonstrate the product as it is	The demonstration is always done with the product as it is. Avoid using slides or other artificial “demo-ware.” This is possible because the product should always be tested (perfected), usable, and completed by the end of the iteration.
It is a conversation	The demonstration is a conversation between the whole team, the product owners, and the stakeholders. They collaborate on what has been done, what has not been done or could not be done, and what the current needs are. It is not a presentation.
Blame-free environment	The team has done what it could do and is forthright about what it could not do. It is not a time to assess blame but to describe the facts about what was really done.
Everyone is present	Everyone has a viewpoint to share. Many ears help to maximize communication. As much as possible, avoid redundancy (waste) in meetings.

Considerations for Transition Phase

Release

Rule	Description
Vision	Product manager and product owner have prepared the product vision and release vision.
Essential stories	Release planning team has identified the essential stories for the next release.
Release plan	Release planning team has populated releases and prioritized MBIs.
Demonstration	Team demonstrated product to key stakeholders.
Retrospection	Retrospection of the release is planned. Retrospections are conducted as appropriate during the release plan.

Iteration Implementation

Activity	Description
Ready for production	Code is potentially ready to be released.
Promote	Release has been successfully executed.
Value extracted from feature for business	Feature has been successfully executed and the business value has been achieved.
Retrospection	Meeting has been conducted to evaluate success of work effort and ways to improve the process.

Product Owner Overview

Overview