Plan Solution (APS03-APS07)

Description

The team decides the start and end dates for the various 2-week sprints over the course of the project and determines their normal operating rhythm for the various sprint ceremonies (Sprint planning, standup meetings, sprint demos, backlog grooming, retrospectives, etc.)

Your sprint schedule should be reflected in your Solution Roadmap (see below)

Who is Involved

• Product Owner

• Scrum Master

• Scrum Team

• Agile Coach (if needed)

Mechanism

• Project Kick-off meeting

• Updated Solution Roadmap

Frequency

Once per project

Outcomes

A definite sprint schedule consisting of:

• Sprint length (i.e. 2 weeks)

• Sprint start/end days of week (i.e. Wednesday to Tuesday)

• Sprint rhythm for ceremonies

Guidelines

• LAUNCH LEGENDS methods will recommend a sprint length of 2 weeks (10 working days).  Shorter sprints make it difficult to completely design/build/test or reduce the number of user stories which are accomplished.  Longer sprints have a tendency to fall victim to over- or under-estimation, scope creep, and a lack of urgency in the cycle

• LAUNCH LEGENDS methods will recommend sprints begin and end mid-week to minimize impact of weekends at beginning/end of sprints and maximize productivity for end of sprint activities

• The operating rhythm should be established to maximize the availability of the various team members and maximize the time spent developing vs. time spent planning.  A typical operating rhythm for a Scrum Team is usually something like the following:

  • Sprint planning:  Day 1 of sprint

  • Daily standups:  Daily, 15 min. time-boxed

  • Backlog grooming:  Between days 7 and 10 of sprint

  • Sprint demo:  Day 10 of sprint

  • Sprint review:  Day 10 of sprint

  • Sprint retrospective:  Day 10 of sprint

• Operating rhythm is open to adjustment during the project at the discretion of the team

  • For example, if in a retrospective meeting the team says stories are not usually detailed enough for good work, more time can be invested in sprint planning.

  • Conversely, if the team feels like they need the full sprint to complete development and timing for the demo is a burden, the demo can be performed later during the next sprint

Description

The team makes initial plans for how many releases are planned for the project and sets dates aligning to sprint schedules.

Normal Agile releases are purposely small (normally 1-4 sprints).

When conducting this activity the team should make sure they understand the following:

• Any hard dependency dates from upstream teams (i.e. if the project is dependent on work other projects need to deliver first)

• Any hard dependency dates for downstream teams (i.e. if there are other projects that will be dependent on the work the project is doing by a certain date)

• Any hard business/market deadlines

• Any other relevant time constraints

Your release schedule should be reflected in your Solution Roadmap (see below)

Who is Involved

• Product Owner

• Scrum Master

• Scrum Team

• LAUNCH LEGENDS IRM

• LAUNCH LEGENDS EA

Mechanism

• Project Kickoff Meeting

• Backlog Grooming meeting(s)

• Updated Solution Roadmap

Frequency

Once at the beginning of a project.  Adjusted (if necessary) in the course of delivery

Outcomes

Planned release dates, names/numbers (if desired)

Guidelines

• To encourage the team to always keep in mind small, working bits of software, establish a baseline for a typical release, such as the project will do a release every 4 sprints

• Consider lead times for external release approvals by other bodies, such as IRM and EA, when planning release dates

  • If lead times/process times are long, consider using the concept of a “Deployment sprint” to allow time to conduct such activities (regression testing, security scans, architecture reviews, etc.)

Description

Configure the Agile Scrum tool and set up the sprints and releases

Set up the project repository for documentation (if different from the Scrum Tool)

Understand the handoffs between the Agile tool and the other LAUNCH LEGENDS SDLC tools

<<To be refined when Agile Tool is procured.  Please stay tuned!>>

Who is Involved

• Scrum Team

• Product Owner

• Scrum Master

Mechanism

• Agile tools

Frequency

Once per project. 

Outcomes

The team should have their Agile Scrum project, sprints and releases established in the Agile Scrum tool (at least the first sprint and release, others can be added later) and have a repository and approach ready for documentation (i.e. in the Scrum Tool, a SharePoint, or a Wiki)

Guidelines

• Make sure your documentation repository supports easy updating and version control

• <<To be refined when Agile Tool is procured.  Please stay tuned!>>

Description

The team should establish a high-level approach for the technology and architecture of the solution to rapidly enable development environments to be stood up and work to begin, as well as for TRB/ARB/ASB engagement to begin as soon as possible if it was not done already.

To facilitate Agile Development, the team should try to establish Continuous Integration/Continuous Build architecture to enable the rapid verification and change needed in the Agile model.  This will make testing and story acceptance easier later in the process.

For Agile projects, it is understood that the solution design will be maintained using Agile principles of documenting only to the extent which adds value at that point in time.  In line with this, Agile teams should complete as much information as is known during their planning sprint, and then update the solution design frequently as the individual user stories, features, and components are designed during the subsequent sprints.

For Agile teams, the solution design might also be maintained in a project wiki, and if so please be sure to reference the solution design artifact template, which provides a good structure for your team to follow in its wiki, which will then be standard for LAUNCH LEGENDS.

Who is Involved

• Product Owner

• Scrum Master

• Scrum Team

• LAUNCH LEGENDS IRM (if needed, see Security section below)

• LAUNCH LEGENDS EA (if needed, see EA section below)

• LAUNCH LEGENDS TRB (if needed per solution path filter, see below)

• LAUNCH LEGENDS ASB (if needed per solution path filter, see below)

• LAUNCH LEGENDS ARB (if needed per solution path filter, see below)

Mechanism

• Design Meeting(s) or Session(s)

• TRB (if needed per Solution Path Filter, see below)

• ARB (if needed per Solution Path Filter, see below)

• ASB (if needed per Solution Path Filter, see below)

• Solution Design Artifact

Frequency

Once at the beginning of a project.  Adjusted (if necessary) in the course of delivery and maintained as a living document

Outcomes

High-level technology and architecture model is defined, documented in the solution design artifact

Guidelines

• Consider the following questions when trying to determine what should be included in the solution design at this stage:

  • If it is something new, are you building, buying, or subscribing?  Are you customizing something that is already a package?

  • If it is an existing system, what is changing or what are you replacing?

  • What is the proposed platform and architecture?

  • What are the planned integrations?

  • How will the system be monitored?

  • Will mobility/mobile access be part of the system?

  • Will the system capture/store/manage data, and how?

  • How will security be ensured?

  • What are the volume and performance needs?

  • What will be the support model?

  • What will be the operations/maintenance model?

• Use existing enterprise standards when possible to minimize need for external review and oversight

• For new technologies, reference industry standards when possible

• The technology and architecture model should be only as detailed as needed to enable work to begin and to get approval from relevant review boards if applicable.  Work with the various technical groups to determine what is needed for a minimal documentation (see below)

• As with all Agile documentation it should be maintained only to the level whereby it adds value and should be perceived as a “living document”

Description

The team should determine when and how the following testing types will be executed in the course of Sprints in accordance with LAUNCH LEGENDS GIT Enterprise Testing Standards.

The following types of testing must be considered when preparing the testing strategy, and it is at the discretion of the project team to determine which are mandatory and applicable in their specific circumstances

• Unit testing

• Functional testing (vs. acceptance criteria)

• Integration testing (with downstream/upstream solutions)

• Performance testing

• Security testing (see separate security section below for more information)

• Regression testing

• Testing automation

• Acceptance testing

NOTE:  For acceptance testing, depending on whether your business has been formally involved in the testing within your sprints, this acceptance testing might already be covered within your functional testing in the sprints.  If this is the case PLEASE BE SURE your business is aware and approves whether their formal acceptance testing will be handled within sprints, or in a separate way (i.e. UAT testing).

Who is Involved

• Product Owner

• Scrum Master

• Scrum Team

• Test Lead

  • NOTE:  This role may be filled by an existing team member also playing another role, i.e. a Product Owner, Project Manager, Developer, Tester, etc. 

• Agile Coach (if needed)

Mechanism

• Meetings

• Testing Strategy Artifact

Frequency

The testing strategy is prepared once per project at the beginning during the planning sprint, and is adjusted (as needed) through the course of delivery if the sprints, rhythm, or other factors change

Outcomes

An agreed-upon testing approach which addresses all of the major testing areas and guidelines for testing BOTH within sprints and outside sprints

Guidelines

• The LAUNCH LEGENDS Centralized Testing Group can assist with guidance on enterprise testing standards and the completion of the testing strategy artifact.  The enterprise testing standards do support models that can facilitate Agile testing, which teams can use (see below)

• Use the concept of “Test-Driven Development”.  Have the developers and testers work together during the design activities of the sprint to determine how the story will be tested and coded according to those standards

• Have developers design their unit tests from a user/feature perspective rather than purely code-based (i.e. have them use real business scenarios)

• The best-case is to strive for all user stories within a sprint to be tested and have zero high-priority defects remaining before the sprint ends

  • NOTE:  In some cases, depending on the project, timelines, or manual-vs-automation mix, some teams can use a model where development and testing sprints are “staggered”.  See below for more information

• Seek to implement automated functional testing from the outset of the project to facilitate maximum regression testing capability for the solution

• Functional testing (traditional test cases) should be tied to individual user stories and should focus ONLY on the acceptance criteria for that story

• Make sure to plan for happy path, alternate path, and edge case/error scenarios when conducting functional testing during sprints, as heavier functional testing during development can enable lighter regression testing

• Bear in mind that as the system grows and the number of user stories delivered increases, the amount of regression testing needed will increase if there is not investment early in automation

  • Plan regression at the “feature level” rather than at the “user story” level, and focus regression testing on happy-path scenarios

  • If manual regression effort is large, consider implementing “Deployment” or “Break-Fix” sprints just prior to a release to enable time to focus on regression testing

• For more details regarding the appropriate level of detail in Agile testing/test scripts, please contact centralized testing services.

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

Test Lead (can be sourced from Centralized Testing Team)

Test Strategy Artifact

I

A

I

R

C

Test Results (acceptance criteria based testing)

I

I

I

I

R/A

End-To-End Test Cases for Release Testing

I

I

I

I

R/A

On-boarding document for resources being added during release sprint

I

I

C

R

R/A

SIT Test Results

I

I

I

I

R/A

Daily Execution Status Reports

I

I

R

R

R/A

Performance Test Scripts & results

I

I

I

I

R/A

Lessons Learned Document

I

A

R

R

R

Description

The team should contact any relevant LAUNCH LEGENDS teams and groups that will be needed to help ensure the project is delivered with quality.  These groups include security, legal, usability, user experience, centralized testing, Infrastructure, support, operations, or any other relevant groups the team or solution path filter has recommended.

Complete guidelines and instructions are included below for the following groups:

• Design Collaboration

• Enterprise Architecture (EA)

• Technology Review Board (TRB)/Architecture Strategy Board (ASB)

• Security & Information Risk Management (IRM)

• Enterprise QA Testing Services (Centralized Testing)

• Usability & User Experience

• Launch Legends Legal

• Launch Legends Procurement

• Global Technology Services ()/Infrastructure

• Launch Legends Support & Operations teams (Coming Soon)

Who is Involved

• Product Owner

• Scrum Master

• Launch Legends Auxiliary groups (see below)

Mechanisms

• Solution backlog template

• Solution roadmap

• Solution design

• Testing strategy

• Agile sprint & release rhythm

• Group-specific materials and meetings (see below)

Frequency

Varies by group (see below)

Outcomes

• Each group has reviewed the backlog, solution design, and testing strategy

• Each group has had an opportunity to recommend changes/additions to the backlog

• Product Owner has prioritized auxiliary inputs to the backlog

• Each group has established and defined a recurring rhythm for engagement with the Agile team throughout their process (i.e. within sprints, outside sprints)

Guidelines

• It is the responsibility of the Product Owner, Scrum Master, and Project Manager to ensure that the appropriate auxiliary groups are engaged for Agile project delivery.

• It is the responsibility of the Product Owner to review the solution backlog with the auxiliary groups to ensure that their needs are met.If not, the product owner must work with the auxiliary group to ensure that any additional work needed for delivery is added to the backlog. This could include:

  • Work that the auxiliary group must perform (usability testing, security scans, etc.)

  • Auxiliary requirements that the team must implement (i.e. password rules, legal brand standards, etc.)

  • Any other work needed to deliver the project that was not already accounted for in the backlog

• It is the responsibility of the Product Owner and Scrum Master to review the release and sprint rhythms with the auxiliary groups and confirm whether additional dependencies need to be added and tracked for their needs. These could include:

  • Lead times needed for auxiliary team work (i.e. security scans before planned releases)

  • Auxiliary group participation in Agile ceremonies (Sprint planning, Sprint demos)

  • Reviews/rhythms/activities that will need to occur outside a sprint cycle (i.e. based on auxiliary availability)

• The Agile team should ask the auxiliary group to make every effort to participate in the rhythms the team has already defined. Work and activity outside a sprint cycle should be minimized.

Inputs

Outputs 

• Design Concept Document produced per Design Collaboration Guidelines 

• Solution Design (Initial)

• Non-functional requirements/backlog items

• Implementation & Support Approach

• Project Charter / Solution Path Filter

• Service Provider Planning notes

• Updated Solution Design

• Feedback captured from forum members and distributed as meeting notes

• Validation, guidance and/or direction needed to achieve cross-functional alignment.   

• Additional or different resource requirements identified and resources committed (now or later)

• Issues/risks identified and/or help with mitigating risks

Contact Information

• PMO

Initial

• Send email with Design Concept document attached to PMO requesting to be scheduled for Design Concept Collaboration session.   

• Send requests by end of day Friday to be scheduled for session in the following week.   

Ongoing/Recurring

• During the meeting, the forum will notify the Agile team if additional reviews are needed.

Re-engagement

• During the meeting, the forum will notify the Agile team if additional reviews are needed.

• Design checks will be part of the pre-deploy process (see sprint execution)

Mechanisms

• Email request

• SPP & Design Collaboration Sharepoint scheduler 

• Design Concept Collaboration Meeting attendance

• Meeting notes

• Design Collaboration Guidelines

• Design Concept Collaboration Forum Guide

Cost and Budget Impacts for Project

• Currently, Design Collaboration engagement activities are not billed back to the project

Activity

Frequency

When

Who

Design Concept Collaboration Meeting

Once

Sprint Zero

Project Team

Ongoing Solution Design Review(s)

Recurring

Sprint Execution

Project Team & potentially Design Collaboration forum members

Design Collaboration Meeting

As Requested by SPP & Design Collaboration Forum

Sprint Execution

Project Team, SPP & Design Collaboration Leaders, Design Collaboration Forum

Pre-Deploy Design Reviews

Recurring

Sprint Execution

Ops & Prod. Support

Leaders

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

Design Collaboration Team

SPP & Design Collaboration Leaders

Design Concept Collaboration Engagement

R

R/A

C

I

I

I

Design Collaboration Scheduling, Facilitation, & Meeting Notes

I

I

I

I

I

R/A

Design Collaboration Forum participation and Feedback 

I

I

I

I

R/A

I

Implementation of feedback/ Updated Solution Design

I

I

A

R

I

Inputs

Outputs 

• Solution Design (Initial)

• Non-functional requirements/backlog items

• Implementation & Support Approach

• Testing Approach

• Updated Solution Design

• EA Reference Architectures

• EA Reference Implementations

• Cloud Formation Template (if needed)

Contact Information

[email, URL]

Initial

• Initial EA engagement should occur during Initiate & Plan Phase with the determination of the Solution Architect and solution path filter and the activities thereafter.

• If EA was not engaged, the team should engage them during the planning sprint for the completion/updating of the solution design artifact.

Ongoing/Recurring

• Leverage existing EA reference architectures and reference implementations to speed project delivery and minimize delays

• Capture EA requirements and constraints in the solution backlog, such as:

  • “Technical” epics

  • “Technical” user stories to obtain signoffs from the EA group separate from other tasks

  •  “Technical” Definition of Done/Acceptance Criteria items in user stories, a clear understanding of what criteria need to be met for stories to be accepted as done (i.e. meets reference architecture, etc.)

NOTE: Teams should leverage EA’s reference architectures and reference implementations from the onset of the project to get a “head start” on building a solution that aligns with their vision

• Invite EA representation to backlog grooming and to any Demos involving Security user stories

• Invite EA representation to any showcases

• Re-evaluate the solution design during every Sprint 0 for subsequent releases to make sure changes are not needed

Re-engagement

• If at ANY time during the course of development new business requirements or technology decisions arise which cause ANY of the solution designs to vary from EA standards for architecture or implementations, EA should be re-engaged

Mechanisms

• Meeting(s)

• Email/written communication/reviews

• TRB/ARB/ASB (see below)

Cost and Budget Impacts for Project

• Currently, EA engagement activities are not billed back to the project

Activity

Frequency

When

Who

Initial Engagement

Once

Initiate & Plan

Project Team

Solution Design Review(s)

Recurring

As needed

EA

“Technical” Solution Backlog Items 

Recurring

Backlog Grooming

Project Team

Sprint Demos/Showcases

Recurring

Every Sprint**

Project Team & EA

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

EA Team

EA Engagement

C

R/A

C

I

I

EA/Technical & Non-functional Requirements, Definition of Done, Acceptance Criteria, etc.

I

A

I

I

R

EA/Technical/Non-functional Solution Backlog Items (based on above)

R

A

I

I

R

Updated Solution Design

C

A

R

R

C

Inputs

Outputs 

• Architecture Change Proposal (plus supporting documentation)

• Solution Assessment Questionnaire

• TRB/ASB/ARB Action items (if needed)

• TRB/ASB/ARB Approval (when fulfilled)

• Updated Solution Design

Contact Information

• [email, URL]

Initial

• Initial TRB/ARB/ASB engagement should occur during Initiate & Plan Phase with the determination of the Solution Path Filter

• If for some reason a new technology is needed and TRB/ARB/ASB was not consulted during I&P

Ongoing/Recurring

• Not applicable

Re-engagement

• If any new technologies are going to be introduced into the project at a later stage, the boards should be re-engaged

Mechanisms

• TRB Review Meeting & Process

• ARB Review Meeting & Process

• ASB Review Meeting & Process

Cost and Budget Impacts for Project

• Not billed to project

Activity

Frequency

When

Who

Preparation of TRB/ARB/ASB Materials

Once

Initiate & Plan

Project Team

TRB Meeting

Once*

Initiate & Plan*

Project Team & TRB

ARB Meeting

Once*

Initiate & Plan*

Project Team & ARB

ASB Meeting

Once*

Initiate & Plan*

Project Team & ASB

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

TRB/ARB/

ASB

Architecture Change Proposal

I

A

R

R

I

Solution Assessment Questionnaire

I

A

R

R

I

Supporting Documentation

I

A

R

R

I

TRB/ARB/ASB Review Meeting

I

A

I

I

R

Action Items/Follow-up activities

I

A

R

R

R

Technology Approval

I

A

I

I

R

Inputs

Outputs 

• Completed Solution Path Filter

• High-Level Technical Requirements

• Solution Design

• Solution Roadmap

• Non-functional requirements/backlog items

• Security Risk Assessment

• Project Playbook

• Identified Security Tier

• Security Requirements/backlog items

• Security Scanning Approach

• Security Scans & Results

Contact Information

• [website URL]

• [CISO] 

Initial

• Initial security engagement should occur during Initiate & Plan Phase (Pre-Agile) with the completion of the solution path filter.  From there, the results from the security output tab should be shared with IRM so they can kick off their processes

• Additionally, if your project is in the process of working through procurement for a new technology or vendor, security will also likely be involved in the security analysis in the procurement process as well.  Be sure to reach out to procurement and security as soon as you know you will be working with procurement.

• For Agile, during the planning sprint the team should meet with security and determine the rhythm of security involvement in the Agile sprints (i.e. product demos, backlog grooming, etc. based on individual project factors).

Ongoing/Recurring

• Capture Security requirements and constraints in the Solution Backlog, such as:

  • “Security” epics to test & confirm compliance

  • “Security” user stories to obtain signoffs from the security group separate from other tasks

  •  “Security” Definition of Done/Acceptance Criteria items in user stories, a clear understanding of what criteria need to be met for stories to be accepted as

NOTE: Teams can use IRM’s Secure Coding Standards to get a “head start” on coding securely

• Invite security representation to backlog grooming and to any demos involving security user stories

• Invite security representation to any showcases

• Engage prior to each release to production to conduct a security scan & remediation of frozen release code

  • If your project is working with an outside agency partner, security will work directly with them to review scan results and remediation steps.  The Scrum Master and Product Owner should be kept in the loop regarding these activities

• Use free tools available to test within every sprint to ensure final code scans are small effort

  • Scanning Tool (unlimited)

  • Source Code Analysis tool (unlimited)

  • Sonarqube

  • Static Analysis

  • Dynamic Analysis

  • OWASP Tools

  • Snyk

  • IRIUS Risk

Re-engagement

• If your project is making changes to an existing system that was already previously scanned, DO NOT ASSUME you will not need another scan.  Proactively re-engage security

• If at ANY time during the course of development new business requirements or technology decisions arise which cause ANY of the original responses of the security section of the solution path filter to CHANGE, security should be re-engaged

• If at ANY time during the course of development, changes are made to the physical design or any other part of the solution design in the course of sprints, make sure to review the changes with security

• If any changes are made to “security” epics or user stories, make sure to review the changes with Security

Mechanisms

• Meeting(s)

• Code Scanning Tools (Secure Code Analysis)

• LAUNCH LEGENDS Secure Coding Standards

• LAUNCH LEGENDS Security Policies

Cost and Budget Impacts for Project

• Currently, IRM engagement activities are not billed back to the project

• Production secure code scans involve a cost of around $3500 per scan

Activity

Frequency

When

Who

Solution Path Filter/Initiation Questionnaire

Once

Initiate & Plan

Project Team

Security Risk Assessment

Once*

Initiate & Plan

Security

Security Project Playbook

Once*

Initiate & Plan

Security

Security Solution Backlog Items 

Recurring

Backlog Grooming

Project Team

Recurring Security Testing 

Recurring

Every Sprint

Project Team

Pre-deployment Security Scanning

Recurring

Once per Release

Security

Scan Remediation & Exceptions

Recurring

Once per Release

Project Team

Sprint Demos/Showcases

Recurring

Every Sprint**

Project Team & Security***

Pre-Release Go/No-Go Checklist

Per Release

Release/Deploy Sprint

Project Team

& Security

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

IRM

LAUNCH LEGENDS Secure Coding Standards

I

I

I

I

R/A

Solution Path Filter/Initiation Questionnaire

R/A

R/A

I

I

I

Security Risk Assessment

C

C

C

I

R/A

Security Project Playbook

C

C

C

I

R/A

Security Requirements, Definition of Done, Acceptance Criteria, etc.

R

A

I

I

C

Security Solution Backlog Items (based on above)

R

A

I

I

C

Security Approach

C

R/A

C

I

C

Recurring Security Testing 

I

I

A

R

C

Pre-deployment Security Scanning

I

I

I

C

R/A

Scan Remediation & Exceptions

I

I

A

R

C

Go/No-Go Checklist

C

A

R

R

C/I

Phase

Inputs

Outputs 

Planning Sprint through Sprint Zero

• Solution Backlog

• Solution Roadmap

• Project Charter

• Draft User Stories

• Functionality and Project Overview Sessions for Testing Team

• Test Strategy Artifact

• Centralized Testing Services Agreement

Sprint Execution

• Approved User Stories and Acceptance Criteria

• Wireframes/Comps/Detailed Requirements for creating End to End Tests

• Sign-off on Test Cases

• Approved Solution Backlog

• Participation in Daily Standup

• Test Results (acceptance criteria based testing)

• End-To-End Test Cases for Release Testing

• On-boarding document for resource being added during release sprint (if needed)

Pre-release

• Code Freeze for the release build during End to End and Performance test execution

• Performance Requirements (Use Cases, Success Criteria)

• Infrastructure monitoring support for performance testing

• SIT Test Results

• Daily Execution Status Reports

• Performance Test Scripts & results

• Lessons Learned Document

Contact Information

• Centralized Testing SharePoint:  

• Centralized Testing Mailbox:  

Initial

• If the team plans to engage Enterprise QA services, they should be contacted during Initiate & Plan if possible to review scope and planned Agile rhythms

• At minimum, the QA team should be engaged and their involvement finalized during the Planning Sprint and for the guidance in the completion of the Test Strategy Artifact in line with LAUNCH LEGENDS Enterprise Testing Standards

Ongoing/Recurring

• If the team engages QA testing services, the QA team will very likely embed one or more testers with the Agile team to effect the recurring testing needed during sprints.

Re-engagement

• At any point during the project the team feels a need for additional testing services

Mechanisms

• Kick-off/engagement Meetings

• Testing Strategy

Cost and Budget Impacts for Project

• Varies depending on project scope, budget, etc.  Please reach out to QA directly for costing estimates.

Activity

Frequency

When

Who

Determine Test Levels to be executed in each sprint (for e.g. component, integration, performance)

Once

Planning Sprint & Sprint Zero

Project Team, Centralized Testing

Determine the tools that will be used for Testing

Once

Planning Sprint & Sprint Zero

Project Team, Centralized Testing

Determine Test Environments

Once

Planning Sprint & Sprint Zero

Project Team, Centralized Testing

Cost Estimation / Level of Efforts

Once

Planning Sprint & Sprint Zero

Centralized Testing

Understand User Stories

Recurring

Every Sprint

Centralized Testing

Participate in daily scrum Meetings

Recurring

Every Sprint

Project Team, Centralized Testing

Review Acceptance Criteria for each user stories and update if required

Recurring

Every Sprint

Centralized Testing

Executing various levels of test based on Acceptance criteria

Recurring

Every Sprint

Centralized Testing

Detailed End-To-End Test Case Creation for Release Testing

Recurring

Every Sprint

Centralized Testing

Provide Demo to product owner

Recurring

Every Sprint

Centralized Testing

End-To-End Functional Testing /SIT

Per Release

Release/Deploy Sprint

Centralized Testing

Daily Defect Calls with Vendor and Company

Per Release

Release/Deploy Sprint

Centralized Testing

Performance Test Planning (Scope, Approach & Environment considerations)

Per Release

Release/Deploy Sprint

Centralized Testing

Performance Test Script Creation and Execution

Per Release

Release/Deploy Sprint

Centralized Testing

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

Test Lead (can be sourced from Centralized Testing Team)

Test Strategy Artifact

I

A

I

R

C

Centralized Testing Services Agreement

R

A

I

I

R

Test Results (acceptance criteria based testing)

I

I

I

I

R/A

End-To-End Test Cases for Release Testing

I

I

I

I

R/A

On-boarding document for resources being added during release sprint

I

I

C

R

R/A

SIT Test Results

I

I

I

I

R/A

Daily Execution Status Reports

I

I

R

R

R/A

Performance Test Scripts & results

I

I

I

I

R/A

Lessons Learned Document

I

A

R

R

R

Inputs

Outputs 

• “Actors”/Target Users

• Solution Vision Statement

• Solution Themes/Goals

• Solution/Product Backlog

• User Stories

• Solution Path Filter - UX team involvement tab

• Usability Guide

• Definition of Done

• Acceptance Criteria

• Standard user experience

• Usability Goals

Contact Information

• [email, URL] 

Initial

• There are questions in the solution path filter that will provide guidance for Agile projects as to whether they need to engage usability or UX services.  If the solution path filter recommends engagement, this should occur during Initiate & Plan, or during the planning sprints

• Involve Usability/UX experts in your vendor selection process during I&P to make sure your agency partners are skilled in the areas desired by LAUNCH LEGENDS

Ongoing/Recurring

• Capture Usability/UX requirements and constraints in the solution backlog, such as:

  • “Usability/UX” epics to test & confirm compliance

  • “Usability/UX” user stories to obtain signoffs from the Usability/UX group separate from other tasks

  • “Usability/UX” Definition of Done/Acceptance Criteria items in user stories, a clear understanding of what criteria need to be met for stories to be accepted as done

• Invite Usability/UX representation to backlog grooming and to any demos involving Usability/UX user stories

• Invite Usability/UX representation to any showcases

  • When possible, use your product demos and showcases as recurring opportunities to conduct high-level usability testing

• Engage prior to each release to production to conduct Usability/UX scan and remediation of frozen release code.

• For reference materials related to these concepts, please reach out to LAUNCH LEGENDS Usability or UX groups.

Re-engagement

• At any point in the project the planned user base changes and requires an analysis of new behaviors and requirements for usability and experience  

Mechanisms

• Meeting(s)

• User Stories

• Acceptance Criteria/Definition of Done

• Usability Testing

• For reference materials, please contact LAUNCH LEGENDS Usability or UX groups

Cost and Budget Impacts for Project

• When applicable, costs will be billed back to the project and will be hourly-based.

Activity

Frequency

When

Who

Initial Engagement

Once

Initiate & Plan

Project Team

Legal Solution Backlog Items 

Recurring

Backlog Grooming

Project Team

Sprint Demos/Showcases

Recurring

Every Sprint

Project Team

Usability Testing

As Needed

Sprint Execution

Usability/UX Team

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

Usability/

UX Team

UX/Usability Engagement

C

R/A

C

I

I

UX/Usability Requirements, Definition of Done, Acceptance Criteria, etc.

I

A

I

I

R

UX/Usability Solution Backlog Items (based on above)

R

A

I

I

R

UX/Usability Approach

C

R/A

C

I

C

Inputs

Outputs 

• Target Users

• Solution Vision Statement

• Solution Themes/Goals

• Solution/Product Backlog

• User Stories

• Legal Requirements/Backlog Items

• Legal Definition of Ready

• Legal Definition of Done

• Legal Approach

Initial

• In cases where pre-SDLC activities such as Ideation, Prototyping, or Initial concepts are undertaken, this is an appropriate time to propose general principles to the legal group for feedback

• Within the SDLC, engagement with the legal group should first occur in the Initiate & Plan phase (IP), particularly during IP01 Determine High Level Business Scope & Objectives and IP10 Review & Refine High Level Business Scope & Objectives.  This will allow the legal team to clarify for the team what legal and technical requirements they will need to consider in the process of establishing their backlog and “Definition of Done” later in the process.

• If Legal engagement has not yet occurred, an Agile team should make sure to engage Legal and get their guidance during the planning sprint in order to make sure the project can add Legal user stories, “Definition of Done” items, or acceptance criteria into their project backlog.

Ongoing/Recurring

• Capture legal requirements and constraints in the solution backlog, such as:

  • “Legal” epics to test and confirm compliance

  • “Legal” user stories to obtain signoffs from the legal group separate from other tasks

  • “Legal” definition of ‘Ready’, a clear understanding of when content/creative/features are approved for development to start

  • “Legal” Definition of Done/Acceptance criteria items in user stories, a clear understanding of what criteria need to be met for stories to be accepted as done

• Invite legal representation to backlog grooming and to any demos involving Legal user stories

• Invite legal representation to any showcases

Re-engagement

• As determined by legal representatives for the project.  If in doubt, re-engage.

Mechanisms

• Meeting(s)

• Demos & Showcases

• User Stories

Cost and Budget Impacts for Project

• N/A (Launch Legends has dedicated attorneys)

Activity

Frequency

When

Who

Initial Engagement

Once

Initiate & Plan

Project Team

Legal Solution Backlog Items 

Recurring

Backlog Grooming

Project Team

Sprint Demos/Showcases

Recurring

Every Sprint**

Project Team

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

Legal Team

Legal Engagement

C

R/A

C

I

I

Legal Requirements, Definition of Done, Acceptance Criteria, etc.

R

A

I

I

C

Legal Solution Backlog Items (based on above)

R

A

I

I

C

Legal Approach

C

R/A

C

I

C

Inputs

Outputs 

• Project Need

• Code of Business Conduct for Suppliers to The Launch Legends Company (COBCS)

• Supplier Guiding Principles (SGP)

• Required Approvals (Delegation of Authority, Local Chart of Authority, local procedures)

• Vendor Master File (VMF)

• Master Data Maintenance (MDM)

• Purchase Order

• Purchased Goods

• Purchased Services

• VMF Updates

• MDM Updates

• Contracts

Contact Information

Hardware & Software

• Acquire Software / Applications from Preferred Vendors 

IT Services, Consultants and Contractors

• Acquire IT Consulting Services and Outside Professional Services 

• Acquire IT Outsourcing Services 

• Non-Employee Workers (NEWs) 

Initial

• Initial EA engagement should occur during Initiate & Plan phase with the determination of the Solution Architect and solution path filter.  At that time it should be clear whether new technologies are needed, and if so both Procurement and the TRB should be engaged

• If for some reason an Agile team was not able to do this during I&P, it should be done during the planning sprint

Ongoing/Recurring

• Engage Procurement as soon as possible at any time during the project where a new business opportunity, need, or problem would necessitate a new technology.

• Since Agile is open to business changes of this sort within the context of a project, it is important for teams to be aware of when changes or the introduction of new technologies might cause delays or problems delivering.  If the team determines the capacity and capability is there to deliver in line with business expectations then they might proceed.  If not, the Product Owner should communicate with stakeholders and determine whether such a change makes sense to be added to the current project, or whether it would be better to initiate a new project.

Re-engagement

• Engage Procurement as soon as possible at any time during the project where a new business opportunity, need, or problem would necessitate a new technology.

• Since Agile is open to business changes of this sort within the context of a project, it is important for teams to be aware of when changes or the introduction of new technologies might cause delays or problems delivering.  If the team determines the capacity and capability is there to deliver in line with business expectations then they might proceed.  If not, the Product Owner should communicate with stakeholders and determine whether such a change makes sense to be added to the current project, or whether it would be better to initiate a new project.

Mechanisms

• For detailed procurement mechanisms and tools, please contact Procurement

Cost and Budget Impacts for Project

• Procurement activities are not billed to projects

Activity

Frequency

When

Who

Initial Engagement Contact

As needed

Initiate & Plan

Project Team

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

Procurement

Team

Initial Engagement

R

R

I

I

C

Inputs

Outputs 

• Service Provider Planning

• Phase-Based Approval contacts

• Solution Path Filter

• Solution Design

• Confirmation of alignment with Annual Business Plan (for prioritization of requests)

• Assigned Infrastructure PM

• Integrated Solution Backlog

• Integrated Solution Roadmap

• Updated Solution Design

• Project Infrastructure & Hardware

Contact Information

• [email, URL]

Initial

• Initial Infrastructure engagement should occur during Initiate & Plan Phase during service provider planning.  At that time it should be clear whether new infrastructure is needed to deliver the project

• If for some reason an Agile team was not able to do this during I&P, it should be done as soon as possible during the planning sprint

Ongoing/Recurring

• From an Agile mindset perspective, the Infrastructure team, when engaged, should be thought of as a parallel team or work stream within the same project, not a separate team.  In this way, both teams should seek to align to the same sprint schedule (or, at least, the same release schedule and Solution Roadmap timelines).  As such, assigned  members supporting the core project should try to participate with the core Agile team in the main Agile ceremonies, and the Agile team should make sure to extend the invitation:

  • Backlog Grooming

  • Sprint Planning Meeting

  • Sprint Demo

  • Sprint Review & Retrospective (if adds value)

  • Daily Standup (during Infra delivery)

• When possible, teams can seek to use/deliver from the same solution backlog, but both teams at a minimum need to make sure to maintain transparency and visibility, which can easily be done using a solution roadmap.

• The Infrastructure team should participate in any release planning activities and in any subsequent Sprint 0 or other execution sprint where infrastructure is needed.

Re-engagement

• The Infrastructure team should be re-engaged any time there is a design or business need change that would require new  infrastructure, changes to existing infrastructure, or any other impacts to infrastructure.

• At minimum,  representation should be brought to any backlog grooming or sprint planning meetings where infrastructure changes are discussed

Mechanisms

• Service Provide Planning

• Planning Sprint

• Sprint Zero

• Solution Backlog

• Solution Roadmap

• Infrastructure participation in Agile team ceremonies

Cost and Budget Impacts for Project

• Infrastructure costs are billed back to the project on a project specific basis.  This will be determined during Initiate & Planning.

Activity

Frequency

When

Who

/Infrastructure Engagement

Once

Initiate & Plan

Project Team

Resource Assignment

Once

I&P Service Provider Planning

Project Team & /Infrastructure Team

Preliminary Solution Design/Infrastructure needs

Once

Planning Sprint

Project Team

Infrastructure Input to Solution Backlog (shared, or coordinated dependencies)

As Needed

Planning Sprint, Sprint Zero, Sprint Execution

/Infrastructure Team

Infrastructure Input to Solution Design

As Needed

Planning Sprint, Sprint Zero, Sprint Execution

/Infrastructure Team

Infrastructure Input to Solution Roadmap (shared, or coordinated dependencies)

As Needed

Planning Sprint, Sprint Zero, Sprint Execution

/Infrastructure Team

Delivery of Infrastructure components and/or user stories

As Needed

Sprint Zero, Sprint Execution

/Infrastructure Team

Phase-based Approvals

As Needed (determined in SPP)

Planning Sprint, Sprint Zero, Sprint Execution

/Infrastructure Team

Activity/Task/Deliverable

Product Owner

Project Manager

Scrum Master

Scrum Team

/ Infra Team

/Infrastructure Engagement

I

R/A

I

I

C

Service Provider Planning

C

R/A

I

I

R

Resource Assignment

I

I

I

I

R/A

Solution Design (Preliminary)

C

A

C

R

C

Infrastructure updates to Solution Design

I

A

I

R

R

Infrastructure User Stories

R/A

I

I

I

R

Infrastructure roadmap/inputs to Solution Roadmap

I

A

C

I

R/A

Infrastructure Delivery

I

A

I

R

R/A

Infrastructure Phase-based Approvals

I

A

I

I

R