2018-12-07 Team Lead Meeting Notes

• @Ashraf

• @Clay Crosby (Unlicensed)

• @Craig Appl (Unlicensed)

• @Sam Im (Deactivated)

• @Wesley Brown

• @Sebastian Brudziński

• Gap Retrospective Meeting Update

  • Going Well

    • Teams have learned and are utilizing the VR dev process

      • Sam: We should ensure that our documentation reflects the current process

    • Teams have gained familiarity with the microservice arch

    • Teams are helping each other

    • A lot of high-value, high-quality work has been completed!

  • Improvements

    • Suggestion to update the Showcase meeting

      • Ashraf: Link work to the product roadmap, more focus on features rather than specific tickets

        • Showcase the progress on a feature

      • Sebastian: Provide more context for work that is being done, how is this getting us closer to our product goals

      • Clay:

        • Team-specific showcases. Other teams can join but focus is for the specific team

        • Each team provide an overall summary

      • Sam: Interested in the team-specific showcase, will get feedback from team

      • Craig: Why are we doing the showcase? Is it to list the work that is done or something else?

        • What is the value for the different roles that are involved

      • Wes: Worry about team-specific showcases causing us to become more siloed

        • Sebastian: Like to hear about what the whole community is working on

      • Clay: Keep current showcase time but only have each team leader join for the whole thing

      • Wes: Focus on high-level for showcase

        • Ashraf: Leave it up to team leads to decide what to showcase and allow for an opportunity for feedback from community

        • Sam: Ticket-level discussions can lead to important insights and requires teams to spend the time to fully think through work. Applies some level of ownership to the person/group showcasing the work

    • Can be difficult to keep the longer-term goals in mind when working on 2 week sprints

    • Are Story Points the best way to capture our work?

      • Would it be easier/better to log actual hours spent on the ticket?

        • Craig/Sam: To granular

        • Sebastian: Story points are not really meant to track work, not sure of another alternative

        • Ashraf: Not perfect but not sure what is better. Learn how to utilize SP's and accurately represent work done

        • Craig: Significant management and community involvement and testing/qa etc are not reflected in SP's. Ensuring that this work is somehow included in the messaging to the consumers of this data

          • Ashraf: There are other KPI's which show our work

    • Looking to get a more consistent velocity

      • Two causes:

        1. Current tickets/usage are not reflecting actual work done

        2. Team resources can fluctuate and result in less work in a given sprint

    • Streamline the dev process

      • Current expectations may require too much overhead

• 3.5 Testing/Release Update/ Other tasks for teams

  • Tasks for code freeze

Mind the Gap (Sam):

• 3.5 Testing

• Designing/Writing tickets for 3.6 work

• Splitting requisitions for multiple suppliers

Parrot (Sebastian):

• 3.5 Regression Testing

• Releasing RCs

• Adding more functional tests in free time

Ona (Craig/Clay): 

• 3.5 Testing

• 3.6 scoping, waiting for feedback based on discussions

JSI (Ashraf):

• Update tickets for 3.5 release

• Complete remaining tickets

• 3.5 Testing

  • Creation of tickets for bugs found during testing

• Shipment file import... has it been tested?

  • Core features are complete but edge cases are not yet complete

  • Sam: Joanna has been involved in testing and so this work has been included for 3.5