Fincrime Scrum Master RCE

Job Descriptions:

Job Role: Scrum Master

Introduction

• This section outlines the roles and responsibilities of a Scrum Master as part of the Agile Methodology.
• The Scrum Master is a servant leader and coach for the Agile Development team.
• Responsibilities
• To the Agile Development Team
• Guide the team in the use of Agile/Scrum practices to ensure value and customer satisfaction.
• Lead the team on self-organizing to fulfill the Agile/Scrum framework.
• Ensure Agile/Scrum concepts and principles are adhered to, must be able to be a voice of reason and mediate in conflicts.
• Facilitate Agile ceremonies (daily standup if requested, planning, demos, retros, backlog refinement) and coordinates the participation of the team in the PI planning ceremonies. Participate in Scrum of Scrums ceremonies.
• Remove impediments to team progress.
• Facilitate discussions to identify alternatives or different approaches, enable decision making, and resolve conflicts.
• Facilitate delivery without coercion, assigning, or dictating the work.
• Support and educates the Product Owner, especially with respect to refinement and maintaining the team backlog.
• Provide support to the team using a servant leadership style whenever possible, and leading by example.
• Help the team grow to a self-organized and high-performance level. Act as a change agent and adapt processes to maximize productivity of the team.
• Regularly push the team out of their comfort zone.
• Guard the team from external requests and disruptions.

To the Organization

• Assess the Scrum Maturity of the team/organization and coaches the team to higher levels of maturity, at a pace that is sustainable and comfortable for the team/organization.
• Embrace new tools and techniques to continuously improve.
• Enable an environment of trust where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of problem solving.
• Assist with internal and external communication.
• Enable disclosure and transparency to the business about development and grows business trust.
• Track team metrics and share progress to team, Product Owner, management and stakeholders.
• Coach the team in the use of metrics for self-improvement.
• Build and share an agile knowledge base.
• Stimulate experimentation among development teams and Scrum Master teams.
• Develop knowledge between Scrum Masters to enhance practices. Should play an active role in the agile community and bring in and spread out agile practices.

Skills

• Good listener, facilitator, emphatic, coach and servant leader.
• Agile practitioner, evangelize agility.
• Agile SME.
• Hyperactive change agent.
• Checklist
• This checklist and templates describe the key items a Scrum Master should address as part of his role and can be customized based on each Product or Team needs.
• PI Planning Readiness
• Before PI Planning begins:
• Move Features targeted for upcoming PI to FY2XQX iteration path, complete the Target Date field and tag them with:
• Service Line tags
• Carry Over features to be tagged: carryover
• Check with the team members if they have received the business context, Intro and closure session invites.
• Send out breakout session invites.
• Capture capacity for the PI, taking into account capacity for the upcoming PI based on team members availability (with local and planned holidays) and velocity of how many story points were delivered in the last PI.
• After PI Planning and before the first Sprint begins
• ADO Feature Timeline should match the PI plan.
• Feature Progress Report should not show open features for the PI that finishes.
• Edit the ADO dashboard for upcoming PI
• Make sure Communication plan is updated
• Sprint Planning
• Before sprint planning, capture capacity for the sprint taking into account team members availability (with local and planned holidays) and velocity of how many story points were delivered in the last few sprints.
• Sprint planning day should be exclusively used for sprint planning, cancel the Daily Stand Up for that day.
• Team should focus on understanding the user stories, estimating them, and creating and estimating tasks for all user stories by the end of the day. If the team doesn’t use tasks, focus on the user story level.
• Send Sprint commitment email with list of scoped user stories and features and sprint goal either on the same day or the very next day to the entire team and copy the Product Manager, Tech Leads and Scrum Masters of the entire train plus train leadership: Engineering Lead, Product Family Lead, Release Train Engineering
• All user stories should have a description and acceptance criteria
• All user stories should be estimated
• During the sprint
• Ensure tasks are updated with completed and remaining effort on a daily basis (if not the sprint burndown chart will be skewed) before the Daily Stand Up. Daily Stand Up article
• On a daily basis, share the outcome of the Daily Stand Up with the team and copy the same list as the sprint commitment. This email should include any blockers identified and actions being taken, any items that came into scope or were removed from scope that day and why. Email template
• Make sure no new user stories are added mid sprint, unless there is a dire need agreed with the Product Owner.
• Conduct a backlog refinement session for the upcoming sprint, this will give you a chance to ascertain completeness of future user stories. Backlog refinement article
• Last day of the sprint
• Conduct a sprint review and demo, share metrics with the team of how the sprint is ending. Cancel Daily Stand Up for that day. Sprint review & demo article
• On top of the mail sent for sprint commitment after sprint planning, send another to the same audience with:
• Sprint outcome: The sprint backlog on the last day of the sprint, summarizing what happened during the sprint: % of completion, carryover items with explanation of delays, items added or removed from scope, significant blockers that impacted delivery.
• Demo: Recording of the demo, and any actions or highlights.
• [Email template
• Conduct a sprint retro and share the outcome retro session only to the team members and Release Train Engineer, Product Family Lead and Engineering Lead. This should include actions and status from previous retros until they are closed.
• Sprint Retro article
• Email template
• Look at PI dashboard and review open risks and issues, they should not overage.
• Check with the Product Owner if any of the features can be marked as closed. Review the program board with the Product Owner to ascertain progress as plan.
• Review team Distribution List and amend if necessary.
• Review team roster published and amend if necessary.
•