Team Commitments
Sprint Pearl
What prevented us from getting the planned work done?
Priorities changed during the sprint - YIM Application - Client needs reprioritized
Not enough research planned for new features
Defects and stories
Issues found pre-deployment - additional testing by Dev and QA in advance of deployment
Support issues came up but tasks were not removed
SDF Work fallen through the cracks due to team turnover - Luis handover
Offboarding process? Documentation as work is completed?
Perfection is not always an attainable or the best outcome
Our team was trying to fix issues that were present in the charting library
Can we get UI/UX feedback on features that have given us trouble?
PDFs, Excel Exports, Charts
YSB 4.2 Deployment
Sprint Cloud Atlas
Goals and tickets are a team commitment, not an individual commitment.
Dev team will take advantage of refinement to dig into language in stories and answer questions/remove ambiguity related to requirements.
Communication between Devs and QA helps keep the process moving smoothly
Questions about prioritization should be discussed daily during standup.
Action Item: Follow up on Accessibility training for Dev and QA.
Team Lessons Learned
Define team strategy and expectations for versioning
@Netal Patel and dev team to prioritize working with OutSystems to research/spin up an internal forge
Team to help @Rebecca Schneider make Project Plan a core part of the process
@Netal Patel to investigate Accessibility Training Opportunities between QA, Dev and Accessibility
Team to commit to more active communication and review in retrospectives
Team to commit to bringing up issues proactively
Developers
Sprint Pearl
Development Team - Versioning can be more complex than a simple check - make sure to estimate accordingly and share with the team.
Review code before estimating
Development Team and QA - Versioning requires additional testing that we are not currently executing
Development Team - Versioning - Post-launch cleanup of versioning needs to be planned for for Dev and QA team (smoke test)
Every release should include a post-launch task of version clean up
Lessons Learned 4.2:
Development Team - Removed Button Functionality
Challenge Assumptions and smoke test functionality (Edit and Add button)
Development and QA Team - Pre-deployment validation and smoke testing
Dedicated pre-launch smoke testing of environment to be deployed (load test)
Lessons Learned 4.3:
Development Team - New functionality built for the first time - very difficult to estimate and plan for
How can we “revisit” things - getting things working != the best, most maintainable version
Opportunities to test lost throughout feature development
As charts were developed, report was not tested
By the time we reached the end, there were significant changes implemented
Planning for Research and creating research subtasks is very important.
Let’s develop best practices around PDF reports and accessibility and implement them during the initial design process
IE, we don’t need to print buttons, drop downs, etc
for highly complex or have gone back and forth to testing many times, 1:1 meetings between testers and devs can be very helpful
YSB 4.2 Deployment
Dev team to walk through the Acceptance Criteria more deliberately in refinement
Dev: User stories needs to be broken down more in refinement and in advance (example: https://yaleits.atlassian.net/browse/CUS-13587 )
Raise red flag further in advance
Estimates need to reflect planning on working on one story at once
Sprint Cloud Atlas
Ask more questions in refinement about specifics in implementation
Example: “Search all text” - is this grant entity only, or all entities?
Involve other technical collaborators during initial planning phase, specifically around system architecture
IE, Data Services
Versioning must be a part of all development moving forward to help with individual deployments
QA and Dev could include system/browser specifics in bugs/defects
Team needs to document standards and practices around PDFs
Action Item: Standardize and document process for ensuring versioning for all features moving forward
Team Lessons Learned
Action Item @Chris Cadden - review the design standard documents in the weekly dev meeting
Action Item: @Chris Cadden to collaborate with @Grecia Briseno to formalize standard documentation of design
Action Item: Dev team to commit to documenting reusable, successful tools in the moment
Action Item: Dev team to review Application Feature Inventory - https://yaleits.atlassian.net/wiki/spaces/CADKS/pages/4049371146
Action Item: @Nestor Rodriguez Ayala and @Chris Cadden to ensure that all documented standards (check lists and templates) include Security and Accessibility planning. If it does not yet exist, create documentation.
QA
Sprint Pearl
Prioritize stories that are ready for UAT to provide time for client changes.
Versioning requires additional testing that we are not currently executing
Pre-deployment validation and smoke testing
Dedicated pre-launch smoke testing of environment to be deployed (load test)
for highly complex or have gone back and forth to testing many times, 1:1 meetings between testers and devs can be very helpful
YSB 4.2 Deployment
Sprint Cloud Atlas
QA and Dev could include system/browser specifics in bugs/defects
Screen size and standard screen resolutions must be standardized & documented for testing and Devs
Team Lessons Learned
Action Item: @Selene Gutierrez and QA team to create standard documentation on process and templates/checklist for UAT
Action Item: @Selene Gutierrez , @Rosa Illescas and @Mauricio Espinoza to work with Omar to formalize Security and Accessibility standards
QA team to share their testing process
BA
YSB 4.2 Deployment
Sprint Cloud Atlas
Team Lessons Learned
Action Item: Pre-kickoff release planning with the entire team
PM
YSB 4.2 Deployment
Sprint Cloud Atlas
Impromptu deployments need to be documented, go through the change process, and signed off on internally before communicated to the client.
Team Lessons Learned
Action Item: Review Project Plan continuously and integrate dev feedback earlier in the process
@Rebecca Schneider to help standardize and publicize documentation across project deliverables
@Rebecca Schneider to present metrics based on estimation vs. actual during retrospectives moving forward
@Netal Patel and @Rebecca Schneider to define metrics to be reviewed
@Rebecca Schneider to review project plans on Mondays to allow for review and feedback of deployment schedule