Ownership and accountability Team need to take ownership of the tasks when they are blocked,

they need to troubleshoot, reach out to the team if needed and get unblocked they need to
collaborate with other teams and get the response. If no response recd in 1 day, people need to
followup next day. They are required to bring an assigned task to completion-

 As the team is following this process, the team will flag the ticket with proper details, if it is
blocked by devops/waiting for PO’s response/3 rd party dependency, the team updates this in
standup-PL section.
 If the story is blocked by any dev or other team members (CAT), the team will directly reach
out to them in teams and discuss the story. Once the blocker is cleared, the flag will be
removed, and the team will proceed with the story by updating the tickets and adding a
comment.

Test cases Every team member should be capable enough to write those Unit test is a must for every
code change. And where not possible, they need to attach supporting artefacts about what and how
it has been tested. People wasted a lot of time setting up the envs and test setup.

 The team is writing test cases for every story which has the feasibility of having Unit tests.
 Only the following stories will not have scope for Test cases- UI (User Interface) changes
having 1 line CSS changes, Migration stories..etc.
 The team will update QA automation whenever AT might be needed or create ticket in the
automation (this task usually is executed by the QA before in hand most of the time and will
add the labels accordingly) if not already added to the board.

Code review very few people participate details to be added, context, testing done, attach artefacts
etc people are added to reviews but they dont review it MRs missed to be attached, people need to
take care of this. We are working to get this automated

 Team adds the MRs after analysis of story when they start working on the story
 Assigning devs to MRs before the MR is ready is not favorable because GitLab sends
notifications, on every change causing clutter for the reviewers. So, the team suggests adding
assignees once the MR is ready to review. This is also agreed with Saurabh on Teams
channel.

Dev need to plan their day well some time for reviews troubleshooting and investigation if needed
(before sprint starts) execute assigned tasks

 Dev has morning standup at BLR, where they plan any peer reviews/discuss on blockages and
plan for the day.
 Senior devs plan out and estimate the tickets when they are available
 Reviews are carried out whenever the MRs become available in the dev-peer review column.

Estimation Everyone should estimate like Anant, Prathima and others, not just Brett (who is gone)
estimations need to improve - they need to get accurate Dev notes not added when people estimate
- like LLD, sol approach so that others can learn and its documented at a single place design and
thought process to be documented
  If no stories are in the current sprint, devs will check with team if any help is needed. Else, if
all the stories are estimated in the next sprint, dev will pick on priority. This is already being
done by the devs.
 If stories are not estimated in next sprint backlog, dev will estimate them. However, there
arises a question of how many sprints into future should the estimation be done for. We
need clarification here.
 Devs while estimating do make their best efforts to add the notes as accurately possible with
the limited amount of work put in without picking up and starting the ticket.

Sprint planning People need to estimate before sprint starts priority order when no work in queue -
estimate all pending items and then pick estimated work for execution people pick work which is not
part of the sprint or the next sprint

Use of Teams Team need to use TMBI Teams and read all the msgs ACK msgs so that we know
when people ahve ready and they agree or disagree. Simple 'thumbsup' is good. collaborate with
other teams if needed, So that discussion is visible to all and everyone can participate when needed
Tag people so that they get alerted Start a conversation

 The details of points went with collaboration with other teams will be recorded in respective
stories and the dev team will be tagged in comments.
 Updating the same in Teams channel may lead to adding same comments additionally on
teams.

Timesheets fill as soon as task is done. Dont wait for the EOD to post all the updates post daily
status updates on the ticket about the progress. This will help us know where we left. Now we have
closed group msgs in JIRA which is less noisy for other stakeholders. attach MR for partial work, if
anyTeam is getting the practice of updating the time records as soon as the task is completed.

 A question from team – should the status of the ticket be updated on the Jira ticket everyday
even though the time logs are added for the progress and status of the ticket is mentioned in
the Daily standup meeting.

Learning team need to learn and ask questions - like how does this work, why we do this etc so that
they know what they are doing Ashwin or anyone else cant spoonfeed or teach everyone share
knowledge, use experienced people for high priority and imp tasks. Delegate repetitive task to
others. like releases

 Team members can learn by going through the MR’s attached and understanding the code
changes instead of asking “how does it works”, etc.
 Regarding the scope outside the tickets, process related work (release activities etc.), senior
devs will ask junior devs to tag along and learn the new process. More suitable approaches are
being explored.
 Dev notes added to Stories, details added to MR’s can help anyone to know and understand the
flow of changes done.