# data[].attributes.body
It feels like there could be a bit more efficiency in the way we handle defects/regressions stemming from changes a developer has made to fix something. I made some significant changes to mc_t20_s1 based on finding that it was not really working correctly all along. Upon testing thankfully Naitik caught that the help button was enabled during the user interaction phase. The fix was a quick one liner but we had to go through the process of a new regression ticket that gets triaged etc. When this feels like it could just go back to dev under the same ticket and be addressed?

Question: What happens when QE finds an issue, how do we handle this most efficiently?
- Code implemented - Producer reviews - Merged to master - Passed to QE for verification
QA prefers to verify code on main
- If Defect is verified as successful but introduces a regression QA prefers to spin up a new ticket to capture

# data[].attributes.body
- this can impact our velocity
- people are also working outside of the sprint
- are there planning or grooming practices that we can adopt to avoid rolling so many pts or set up sprints so all work can be completed with-in a sprint?
- 1/2 tickets rolling as exception might be ok but rolling pts overtime can inflate impact our velocity which can make it hard to use data for planning

# data[].attributes.body
Reviewing burn down chart periodically has helped us have better discussions

Practices:
- to reduce # of tickets rolling, review before planning
- If we're getting close to sprint end, review tickets either timebox or spin up new ticket for follow on work if we've surpassed the scope of the ticket (acceptance criteria has been met)
- if acceptance criteria has NOT been met - ticket should remain whole
- A couple of days ahead of sprint close review tickets and see what can be closed - follow above practices

# data[].attributes.body
ex: "Alpha, Beta, Gold" Process

Practices:
- We do not want QA testing to be completely removed from the development
- If a ticket has QA work involved tackle these stories first (sprint end is heavy on QA)
- If there is work that might roll can we swarm?
- ask before going to next sprint to pull work
- maybe leave more unnassigned ( if it makes sense) & continue to communicate

# data[].attributes.body
The reduced meeting load has been helpful in streamlining decision-making, and does not seem to have adversely affected the overall workflow

- mtg prep (continue)
- research to get ahead of mtgs

# data[].attributes.body
is everyone comfortable with pointing?
What feels like it's working or isn't?
Has anyone ever used a story point reference chart? Any interest in starting to build one out?

Discussion:
- 1,2,3 etc - do we all have the same understanding of what a 3 is?
-

# data[].attributes.body
We should take one last look before we close this action from last retro to make sure we agree on a start

https://confluence.cainc.com/display/TV/Definition+of+Ready

https://confluence.cainc.com/display/TV/Definition+of+Done?src=contextnavpagetreemode

# data[].attributes.body
when tehre's a difference in votes, should folks get to speak to why they voted they way they did?

Practice:
- even if there is a vast majority leaving a pause / op
- Team should feel empowered to speak up for an alternate value

# data[].attributes.body
1. Challenges?
2. Are we staying focused in discussion?
3. Planit tool. is it working? do we want to keep it going?

Notes:
Challenges:
- keeping discussions focused & deep enough to help ticket meet definition of ready (currently feels like discussions are lengthy)
- pts don't have to be perfect, they are a relative est.
- try timeboxing
- focus for grooming - is it based on priority?
- great input & questions

New Practice to Try:
- time boxing
- Keeping discussions focused to
- Lean more on pre-planning mtgs & slack channel to order BL & communicate
- Use PL for adhoc grooming, priority discussions

# data[].attributes.headline
Pointing Chart & Pointing Practice Basics 

# data[].attributes.subject
Pointing Chart & Pointing Practice Basics 

# data[].attributes.body
Revisit what points represent - complexity v time spent
Create a story point reference chart

# data[].attributes.headline
Triage "training" for student facing teams

# data[].attributes.subject
Triage "training" for student facing teams

# data[].attributes.body
For one-off odd ball defects, it would be good to help PO and student facing teams have a common understanding of how to think about what's a priority.

- related to Chrome touch issues
- many conversations around whether or not a defect should be fixed
- different from normal defect triage
- when we are faced with defects that are live in production
- work level was larger than initially expected

Re-point Ticket?
- do we re-point?
- if something is larger than we had thought do we continue?

# data[].attributes.headline
Pointing - dev/dsn work, PLUS QA effort, or excluding that? Separate tix (subtasks) for dev, dsn, QA, each getting their own points?

# data[].attributes.subject
Pointing - dev/dsn work, PLUS QA effort, or excluding that? Separate tix (subtasks) for dev, dsn, QA, each getting their own points?

# data[].attributes.body
- defects / CR's might make sense for this to be 1 ticket
- new renderer development, single ticket with subtasks may work
- new renderers seem to be the area where we may not be clear, esp. in instance where we are adding a11y. where a11y work was not initially included in ticket
- common or past practice: dev ticket is passed to QA and then reviewed with Product
- Current practice: determine at the start of planning what makes the most sense as far as how to split up the work.
- for a11y work, same as above we should discuss case by case

# data[].attributes.body
This is a very high-powered team, and we don't have a lot of work right now. We have some work in the pipeline, but it's not quite ready yet (e.g., keyboard nav for K-2).

# data[].attributes.body
All devs are really helping each other out I don't think any blockers have been blocking for long!

All working together for the first time - great to see chat & communication.

slack has been working well

ALL devs are so helpful & feel like they can be leaned on for support - all are WILLING to help

# data[].attributes.body
We have some of the best Devs and QE at CA. Feel so fortunate!

# data[].attributes.body
- is there any value in being consistent with those used by other teams? (for larger crossteam filters/boards)

# data[].attributes.body
Votes or thoughts on using this moving forward vs the Zoom video panel to share votes?

benefits:
- can see a list of tickets ahead of time
- easier to gather votes with a bigger team (video can be challenging)

Drawback:
- Ticket is not linked to plan it poker

In Practice:
- Prod screen share ticket
- AL managed plan it poker

# data[].attributes.body
Upgrading to the latest version of interactjs didn't fix the chrometouch issue. Not exactly sure the best way to go forward. Should we move forward with the upgrade as standalone and then address the chrometouch issues separately?

Challenge:
Library we use for drag & drop is out of date. Was able to upgrade, but did not fix the Chrome issue, might be related to the way we Chrome.

Lesson Learned: for 3rd party libraries we may want to take a different approach - upgrade and then fix or fix in legacy. May depend on risk, as far as how we handle.

# data[].attributes.body
https://jira.cainc.com/browse/RDG-51- Might be better to split these type of items up into an initial spike where the POC can be coded and dev team can review. Then we spend however long it takes getting cross team buy in and then we spin up a ticket to implement. Not sure if there is a good way to spin up the implementation and block and/or schedule so we can plan correctly?

Retro Notes:
- New Practice: may want to make sure we spend the time in planning discussion to discuss approach on these kinds of tickets
- May have just been a factor of new sprint, team forming & getting work into queue
- New Practice: Product summary that explains in business terms what is valuable. Should start with a simple template

# data[].attributes.headline
How do we want to tag content defects in the backlog?

# data[].attributes.subject
How do we want to tag content defects in the backlog?

# data[].attributes.body
How might we make this more efficient? PM's ping in the channel with a reminder prior to grooming but not sure if everyone is reviewing tickets prior to the meeting.

# data[].attributes.body
For setting up a Jira Q & A session

# data[].attributes.body
New team members have shared the need for better understanding our technical development approach (and all the acronyms/terms). How might we support the efficient onboarding of new team members?

# data[].attributes.body
For completing his first grooming session and the fun e-scrum/weekend question.

# data[].attributes.body
For identifying the need to have a more efficient way for Devs to find renderer assets.

# data[].attributes.body
Awesome testing, thank you for catching everything!

# data[].attributes.body
One thing that has always concerned me is that our master/main branches are not always deployable meaning that code gets merged into there before it is tested. I have had good experience in the past working with an integration or sprint branch that serves as the working branch during a sprint and things are only moved into master once confirmed by QE. Is this something we might want to look into doing this way we can always be sure that master could go live at any point in time.

# data[].attributes.body
For being a patient and super thorough mentor.

# data[].attributes.headline
Thanks Chris, for digging into a stumper issue on getting nightwatch-local automation running (new machine setup stuff!)

# data[].attributes.subject
Thanks Chris, for digging into a stumper issue on getting nightwatch-local automation running (new machine setup stuff!)

# data[].attributes.body
Specific to new renderer or feature or reskin
Versioning
JR Walker - Start offline
1. Draft
2. Review Team