When a new program is approved and initial teams are assigned, the program enters a discovery phase. The discovery phase starts with the “Program Brief” produced by the Product team. The “Program Brief” identifies the program objectives which are used to produce a workable design and high-level backlog during the discovery phase. The design should be just thorough enough to identify the major new and impacted components and workflows. It is not a full design where everything is known up front and does not change during the implementation phase (not a waterfall approach). The high-level backlog should include Milestones (Themes) and Epics.
The players involved in the discovery phase are the following:
At the end of the discovery phase there should be a completed “Program Design” document, high-level Milestones and Epics defined in the backlog, and rough estimates to complete the program. The Program Team, especially the Principal, should be comfortable that the design serves to focus and direct the Development Teams. This information will be presented at a “Program Discovery Review” meeting.
The discovery phase is expected to only take one or two sprints to complete but is dependent on the number of unknowns for the program and the availability of the teams to participate. The time to complete should be shorter for programs involving existing products than programs that must create new services. The Software Development Leadership Team (SDLT) should be notified if more time is required to complete the discovery phase than expected.
The “Program Brief” will identify the major program objectives. From this information, new and impacted components and workflows should be identified. The technical leads for the program (e.g. Partner and Principal Technologist) engage in research and design activities like Event Storming to identify workflows and components. At the conclusion of discovery, there will normally still be unknowns that will be answered during the execution of the program. Throughout the discovery phase the SPM should be available to aide in clarifying the program requirements.
Toward the conclusion of the discovery phase, workflows are decomposed into Epics by the technical leads and EPM by looking for natural breaks in delivering the workflow. Each Epic should be end-to-end demonstrable. For example, one Epic could be the “happy path” operation followed an Epic that includes advanced and edge-case handling. Workflows typically span no more than four Epics. The Epics can be tagged with a workflow identifier to drive backlog queries.
The Program Team organizes Epics into Milestones based on the design, resource constraints (development teams), and market concerns (customer engagements or events). Organizing Epics into Milestones may trigger further refinement of Epics. Milestones that trigger Lighthouse engagements should be clearly marked.
Once the backlog is organized, the technical leads along with the Engineering Managers for each team provide rough estimates for the Milestones. The estimates provide relative sizes to help the Software Development Leadership Team (SDLT) and the Business Unit Leadership Team (BLT) make decisions about the program.
Results of the discovery phase are documented by the Partner Technologist with the help of the technical leaders on the program in the “Program Design” document. The “Program Design” document should aid the onboarding and early direction for development teams, shortening the time required for those teams to become productive. It is important to remember that the Staff involved in the discovery phase may not represent the development teams that are eventually assigned to the program.
At the conclusion of the discovery phase, a “Program Discovery Review” meeting is held to present results of the discovery phase. This meeting is attended by the BLT, SDLT, and Program Team.
The meeting is for one hour where the first 10 minutes are reserved for reviewing the Executive Summary of the Program Design Document. The Executive Summary includes the first four sections of the Program Design Document (Background, System Components, Deliverables, and Risks/Concerns).
The Principal is responsible for presenting the Executive Summary to the BLT and SDLT highlighting the changes and additions to products. The presentation is interactive including questions and answers during the presentation. The EPM presents the backlog highlighting milestones, estimates, and risks.
The expected results of this meeting are one of the following: