Mark for Deletion - Vega - Retrospective / Action Plan/ Best practices list

Mark for Deletion - Vega - Retrospective / Action Plan/ Best practices list

Action Plan

Notes

Action Plan

Notes













@Alexander Kurash Investigate the problem with Karate



Review prioritization the backlog every time a new item is added



Invite Holly to Groomings and Daily Scrums to discuss open issues



Vega team: If an item requires effort form other platform (not the one the item was assigned to, ie FE/QA etc.) discuss if the work on the current ticket should be continued within the estimated effort or  another ticket should be created for other platform, and set priority for the work



Ensure a formal hand-off for mod-pubsub happens @Taisiya Trunova @Darcy Branchini



Vega team: 5 SP should be the maximum estimate for an issue in a Sprint. And if an issue appear to be big at grooming, try to spit it into smaller pieces 



Vega team: Prioritize Sprint Backlog at Sprint Planning







@Taisiya Trunova



Vega Team: include risks into RMB upgrade estimations

Moved to BP

Vera Team: finish development on Wednesday evening and reserve Thursday and Friday for code reviews, comments fulfillment, etc

Moved to BP

@Darcy Branchini review the completed tickets up to the end of sprint



@Taisiya Trunova Feature readiness check list+AC so that to track bugs vs new functionality



Type your task here, using "@" to assign to a user and "//" to select a due date



















R1 Release Retro

@Darcy Branchini To discuss who will be next pubsub maintainers on SoS meeting



@Tetyana Afanasyeva to clarify what the definition of done for Karate tests is now that we don't integrate them with TestRail anymore

done

UI team to think how to improve the speed of internal PR reviews @Dmitriy Litvinenko



To document contracts after discusion



@Darcy Branchini to discuss PO involvement/engagement throughout the development process on PO's meeting



Make sure all tickets are pointed before team started working on them (added to the sprint)



To do a root cause analisys for R1 bugs @Dmitriy Litvinenko @Alexander Kurash to create tasks for this activity



Q3 Release Retro

To start create and run performance tests @Alexander Kurash



Develop a process of deploying and testing of scratch env. @Alexander Kurash

done

Be more conservative with estimates

done

To clarify R2 scope @Darcy Branchini

done

Q2 Release Retro

POs to check In review tickets frequently



To discuss difference between Snapshot and other envs issues on Sos and Tech Leads meetings



POs to stay involved in prioritization process



To review features for Q4 on Grooming meetings to be better prepared for Q4 planning



Q1 Release Retro

It would be nice Zak (or someone else) to fix memory leaks



@Tetyana Afanasyeva To discuss bug fix release communication issues with Release coordinator

done

@Tetyana Afanasyeva To discuss bug's life cycle with POs and with the team in order to be on the same page

done

@Tetyana Afanasyeva To setup a meeting with TLs and Darcy to discuss Q2 scope

done

@Alexander Kurash TL to create a release check list

not relevant

During release cycle POs need to test features on some environment that is similar to BugFest (data is not deleted every day; large amount of data), but built from master branch regularly. Can snapshot-core-continuous.dev.folio.org be such an environment?



Team to do a demo for completed stories in the sprint

done

Reduce committed scope for the sprint

done

TLs to organized estimation of groomed stories within 2 days after a grooming

done

Sprint 32-34

Agreed not to point stories during grooming meeting. BE or FE team point groomed stories later separately.

done

@Anna Melnyk to send Darcy an example of video demo from Cate.

done

In order to make standups shorter agreed:

- anyone who is not interested in standup's demos could skip them.

- back to this question again after onboarded people leave the team.



The team to provide a feedback about stories' description.

done

Sprint 27-29

BE devs to investigate and describe all technical details for BE stories before taking in work (not just a copy-past of initial story).



Sprint 24-26

Agreed to change Tester Assignee for tickets which are waiting for review for more than 3 days.



Sprint 21-23

To organize a separate meeting for spike discussion with PO, Folio Tech Lead and Vega team before estimating and taking a Spike to sprint.



Sprint 18-20 retro

no action items



Sprint 15-17 Retro

@Tetyana Afanasyeva to organize a meeting with Core team in order to resolve blockers if any.

done

PO to provide with expected result and use cases for spikes.



@Khalilah Gambrell to discuss upcoming features with other POs in order to add UI stories in the backlog; pull in stripes-related work; pull in UI defects.



Sprint 11-14 Retro

@Maxim Didenko and @Kostyantyn Khodarev to consider what can be added to tech debt backlog

done: nothing to be added

Sprint 9-10 Retro


@Maxim Didenko to create Tech Debt story

done

@Tetyana Afanasyeva to discuss a separate environment for release candidate review on SoS meeting

done

Devs to add video capture for bugs presentation to POs



Revisit DoD to ensure we are aligned.

done

Best practices list

Best practice

Note

Best practice

Note

Include risks into RMB upgrade estimations



Finish development on Wednesday evening and reserve Thursday and Friday for code reviews, comments fulfillment, etc



5 SP should be the maximum estimate for an issue in a Sprint. And if an issue appear to be big at grooming, try to spit it into smaller pieces