Job Description: Scrum Master is needed to perform the following duties:
Facilitating daily stand-up meetings
->In Scrum, on each day of a sprint, the team holds a daily scrum meeting called the "daily scrum." Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant. The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team member answers the following three questions: What did you do yesterday? What will you do today? Are there any impediments in your way? By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains.
Responsible to run Scrum of Scrums
->A technique to scale Scrum up to large groups, consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as "ambassador" to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. Depending on the context, ambassadors may be technical contributors, or each team's Scrum Master, or even managers of each team. The Scrum of Scrums proceeds otherwise as a normal daily meeting, with ambassadors reporting completions, next steps and impediments on behalf of the teams they represent. Resolution of impediments is expected to focus on the challenges of coordination between the teams; solutions may entail agreeing to interfaces between teams, negotiating responsibility boundaries, etc. The Scrum of Scrum will track these items via a backlog of its own, where each item contributes to improving between-team coordination.
->Involve in continuous sprint planning and monitoring
The Iteration or Sprint Planning meeting is for team members to plan and agree on the stories or backlog items they are confident they can complete during the sprint and identify the detailed tasks and tests for delivery and acceptance. Iteration lengths typically range between 1 and 4 weeks. The team holds a planning meeting at the beginning of each iteration to break down each of the features scheduled for the iteration into specific technical tasks. Iteration or agile sprint planning meetings generally last from 2-4 hours • any more than that and you may be spending too much time in unnecessary planning; less time than that and you may not be doing enough planning and collaborating. Sprint planning is a time boxed working session that lasts roughly 1 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team's velocity or capacity and the length of the sprint.Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment. The Planning Steps are below:• Remind the team of the big picture or goal• Discuss any new information that may impact the plan• Present the velocity to be used for this release.• Confirm team capacity.• Confirm any currently known issues and concerns and record as appropriate. • Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint. • Present proposed product backlog items to consider for the sprint backlog. • Determine the needs, sign up for work, and estimate the work owned. • Product Owner answers clarifying questions and elaborates acceptance criteria. • Confirm any new issues and concerns raised during meeting and record. • Confirm any assumptions or dependencies discovered during planning and record. • ScrumMaster calls for a group consensus on the plan.
Provide Issue/Impediment SolutionAs the Scrum Master, work together with the team to determine which impediments it may resolve itself and what support it needs. Over time, the team should become capable of removing more and more impediments on its own. Don't simply delegate all impediments to the team, however. Many of them will be too hard for the team to resolve on its own. Impediments can slow down or even halt the progress of an otherwise well-functioning Scrum team. Let's take a look at the most common challenges that crop up on teams and what steps you can take to resolve them.o Problems:• If the impediment backlog lives in the mysterious black book of the ScrumMaster, you have a problem. • If your impediment backlog does not change you have a problem. • If your impediment backlog is empty, you have a problem. • If you have an impediment backlog with a growing number of active impediments, you have a problem. • If the ScrumMaster resolves all impediments himself you have a problem.
- Make the impediments visible - Write the impediments on a flipchart or index cards and attach them to a wall in the team room near the task board. Make sure that everybody can see the impediments, especially the team during the Daily Scrum. Some of the impediments are really hard to solve. Hiding these will make it very easy to ignore the impediments while making them visible creates pressure to resolve the impediments. Putting impediments near the task board creates a nice opportunity for you as the ScrumMaster to give information during the Daily Scrum, like • I resolved impediment X. What do you think is now the impediment with the highest priority? I will pick that one.• That way, it becomes very clear if the ScrumMaster neglects to continuously remove impediments.
- Search for impediments - There is no such thing as a team without impediments -- every team could perform faster. If you as the ScrumMaster aren't aware of impediments you are not doing your job. Inexperienced Scrum teams may not mention impediments by themselves so you must actively search for them. For example: Whenever there is no movement on the task board during the Daily Scrum, it is likely that there is an impediment. If there are more tasks • in progress• on the task board than developers on the team, it is likely that there is an impediment. Ask the team about these things and you will discover the impediment. Question the team about what things that would help them accomplish their tasks faster. Remind team members that these are also impediments to achieving the highest possible performance.
- Limit the number of impediments -There are several strategies you can use to limit impediments. One is to limit the time; another is to limit the number of impediments. To limit time, use a strict rule, like: • An impediment may only exist for a maximum of 24 hours.• After that time it must either be resolved or trashed. A trashed impediment may only come back in the next Sprint but not the current one. To limit the number, set a maximum limit of open impediments (e.g. 4). When writing impediments on index cards and attaching them to the wall you could limit the space for the cards so it's simply not possible to attach more impediments to the wall. When you have reached the maximum of open impediments and a new impediment is discovered, you'll have to decide if the new impediment is more important than the existing ones. If this is the case, remove an existing card and put the new one in its place. Of course, new impediments typically occur much faster than you can remove them. That results in an ever-growing list of open impediments and after a short period of time you have a very long list of impediments. That blocks focus, makes prioritization hard, and creates a bad mood. Don't manage impediments, resolve them! Don't be afraid to miss important impediments: they will be raised again later.
- Differentiate between local and global impediments - Differentiate between impediments that slow down the team and those that block progress on stories. The first category of impediments could be called global impediments and the second category could be called local impediments (or blockers). Use tip number three to address global impediments. For local impediments, attach red sticky notes to the stories on the task board. Don't be afraid to use as many sticky notes as you need. Be aware, however, that tip number three has a pitfall: There may be impediments that block stories. Trashing these impediments would cause problems since the blocks won't vanish. Tip number three covers global impediments but the local ones, so put as many local impediments on the task board as you discover.
- Help the team to resolve impediments As the ScrumMaster, don't resolve all impediments by yourself. Work together with the team to determine which impediments it may resolve itself and what support it needs. Over time, the team should become capable of removing more and more impediments on its own. Don't simply delegate all impediments to the team, however. Many of them will be too hard for the team to resolve on its own
Run Agile ceremonies like Sprint planning, daily Scrum meetings, backlog grooming, Sprint review and Sprint retrospectives; • The sprint planning happens just before the sprint begins and usually lasts one to two hours. Coming into the meeting, the product owner will have a prioritized list of the product backlog items. The product owner discusses each item or user story with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast, normally based on the team's velocity, outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog. The daily stand-up meeting is designed to quickly inform everyone of what's going on across the team. It is not supposed to be a detailed status meeting. The tone should be light and fun, but informative. Have each team member answer the following questions: What did I complete yesterday? What will I work on today? Am I blocked by anything? The daily stand-up occurs once a day, normally in the morning and requires the development team, Scrum Master, and Product Owner to attend. It is advised that the duration is no more than 15 minutes, hence the purpose of standing up to keep the meeting short. At the end of the sprint, each team gets to demo or showcase their newly developed features or just generally what they worked on during the sprint. This is the time for the team to celebrate their accomplishments demonstrate work finished within the iteration, and get immediate feedback from project stakeholders. The duration can vary on the number of items to showcase per team. The work is usually showcased to participants of the respective team, namely the development team, Scrum Master, and Product Owner as well as other teams and project stakeholders. And finally, on to the sprint retrospective which occurs at the end of the sprint, typically after the sprint demo and lasts about one hour. Participants are the development team, Scrum Master, and Product Owner. Sprint retrospectives shouldn't be just for making complaints without taking action. Retrospectives are a means to identify what's working so the team can continue to focus on those areas and also what's not working so the team can discuss and collaborate to find creative solutions to the problemsCoaching scrum team throughout the sprints on agile principles, methodologies and best practices;
• The Scrum Master coaches the Scrum Team in fulfilling their roles and effective use of the Scrum framework. The Scrum Master also coaches the organization in its Scrum adoption. Coaching enhances our ability to learn, make changes, and achieve desired goals. Coaching is a thought-provoking and creative process that enables people to make conscious decisions and empowers them to become leaders in their own lives. Understand what matters most to people. Focus on what people want. Remember that this is not about you. Remove judgment. Don't be afraid to challenge people. Work on yourself to better serve others. • Help the team to understand the difference between Waterfall model and agile development model. Agile methodologies all started based on four core principles as outlined in the Agile Manifesto. These methodologies are rooted in adaptive planning, early delivery and continuous improvement, all with an eye toward being able to respond to change quickly and easily. AGILE methodology is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. Both development and testing activities are concurrent unlike the Waterfall model. The agile software development emphasizes on four core values.• Individual and team interactions over processes and tools. • Working software over comprehensive documentation. • Customer collaboration over contract negotiation. • Responding to change over following a plan
Manage Agile metrics like (Sprint burn down, burn up, velocity, sprint backlog) on RTC and present to the team and management on regular basis; • During the building of an iteration, while the developers are focused on creating the features they have committed to delivering, the project manager is responsible for understanding the progress that the team is making and keeping the stakeholders informed of the project's progress. Iteration Status Chart - is an example of a chart that project managers can use to communicate iteration status to the customer & stakeholder community. Burn-Down Chart - The project manager starts at the upper left-hand corner of the chart, before any development work is completed and as features are completed or • burned down,• the project manager tracks that progress with a simple line chart. Applying Earned Value Management - requires initial baselines, such as number of planned iterations, number of planned story points in a release, and planned budget for the release. Also needed are the total number of story points completed, number of iterations completed, actual cost, and the number of story points added or deleted from the release plan.
Work closely with team in estimates (planning poker and affinity);• Preparation of the estimates is one of the important parts before we start the Sprint. Discussion with the development team on the estimates of time lines, budget required to