Search

How To Prioritise Requirements With The MoSCoW Technique

IntroductionOn most projects, we talk about requirements and features that are either in scope or out of scope. But to manage those requirements effectively we also have to prioritise them. And this is where the MoSCoW technique comes in.Let me explain what M, S, C, and W stand for.M is a must-have requirement. Something that’s essential to the project and that’s not negotiable.S is a should-have requirement. Something we need in the project if at all possible.C stands for could-have. Something that’s nice to have in case we have extra time and budget.W is a will not have requirement. Something that’s out of scope, at least this time around.Why to use MoSCoW technique for requirement prioritization?Using the MoSCoW technique gives us a more granular view of what is in or out of scope of the project, and it helps us deliver the most important requirements to the customer first. In other words, it helps you to manage your client’s expectations. And as you will come to see, the MoSCoW technique can also be used to delegate work and to be explicit about what needs to get done and what doesn't need to get done.Whenever I train people in the fundamentals of project management, I always teach them the MoSCoW technique. And without a fail, it ends up being one of the most useful techniques, due to its applicability and simplicity. It can even be used outside of the project space. And, if you still wonder how we arrived at MoSCoW, then we’ve simply added two o’s to turn the four letters into a memorable city name.How to use MoSCoW technique for requirement prioritization?Let us look at an example of how to use the technique in practice. I would like you to imagine that your job is to project manage an upcoming conference. This is a yearly conference where delegates will come to network and to hear industry experts talk about sustainability in project management.M- MustAs you meet with the organisation behind the event, i.e. your client, you ask them what their must-have requirements are for the conference. You are curious to know everything you must deliver to them for them to be satisfied. Your client responds that the event must be held at an indoor venue within five kilometres of the city centre and that it must be within the allocated budget. It must be able to host 150 people and it must have facilities to serve lunch.S- ShouldYou then ask your client what there should be at the event if at all possible. They answer that you should arrange for three speakers in the morning and three speakers in the afternoon. All of them should be recognised within the industry, if at all possible. In addition, you should make time for the delegates to network with each other during lunch, and lunch should, ideally, be a sit down affair with hot food. Finally, each delegate should receive a goodie bag upon arrival.C-CouldYou furthermore enquire with your client what there could be at the event. i.e. what are some nice to have requirements, which you could incorporate? You’re not promising to deliver those requirements but in case you have extra time and budget you can look into it. It turns out that your client would like to have a famous sports or businessperson open the conference. But it’s not essential and only possible if budget allows. They also think that it would be nice with a panel discussion on sustainability at some point after lunch, but it isn’t essential.W- WouldYou finally ask them what there will not be at this event, i.e. which requirements are firmly out of scope. Your client answers that there will not be multiple tracks of speakers and that there will not be any alcohol served at any point during the day. They also specify that this year there won’t be a second day of in depth workshops taking place.Using the MoSCoW technique in this way to categorise all the project’s requirements is a very user-friendly method, which your client will be able to easily understand. Initially your client may say that everything is a must-have requirement, but when you explain that must-have requirements come with a price-tag they will understand that they can’t have everything unless they increase the budget and give you more time to deliver it.When you plan your project, and put together the project plan, only include the must-have and should-have items. This is what you’re promising to deliver. You’re not promising to deliver the could-have items. They can go on a separate wish list. Also take care to properly document the will-not-have requirements. You may think that you can forget about them because they are out of scope. But, it’s necessary to document them as you may have to refer back to them later.An example of using the MoSCoW technique to describe features of a requirementWhat I really like about the MoSCoW technique is that you can also use it at a more detailed level to describe the features of a requirement. Let’s say for example that you have delegated the goodie-bag-task to one of your team members. That’s the little bag each participant will receive when they arrive at the venue and which normally contains a few freebies. It’s the team member’s job to gather the detailed requirements for the goodie-bag and to physically produce it.As you’re delegating the task, the team members would like to know what your expectations are and what they must deliver to you at the end. You should explain them all the information required clearly, such as:The requirements (M):There must be 150 goodie bagsEach bag must contain a copy of the event programme andBag as well as the event programme must be made out of recyclable materialsThe deliverables (S):There should be two free branded items inside, such as a pen and paper, if at all possible.Furthermore, explain that (C):The bag could contain something sweet, like mints, but only if a suitable sponsor is found.The bag could also contain a small bottle of water as a nice to have.Finally specify that (W):The bags will not contain any alcohol and that the combined weight will not be more than one kg.Whose responsibility is to prioritize?Business Analysts are mainly responsible to take up the most complex requirements and break down them into simple tasks that can be implemented by anyone. But, BA alone can’t do the prioritization alone. He/she needs to bring in several stakeholders  into the process and get their approval on the requirements priority. It is essential for BA to understand the dependencies between the requirements before prioritizing them.Benefits of using MoSCoW technique for Business AnalystsThe BA can make use of any prioritization techniques to prioritize the requirements thoroughly. But, MoSCoW technique is the effective one to use among all the other prioritization techniques available. Some of the benefits of using MoSCoW technique for Business Analysts is shown in the figure below.ConclusionAs we can see that we can prioritise requirements with MoSCoW technique at a high level but also at a low level to specify the detailed requirements, or features, of a product. When you use it at a low level it also helps you to delegate tasks better to team members and to set expectations. Are you ready to give it a go?
Rated 4.0/5 based on 3 customer reviews

How To Prioritise Requirements With The MoSCoW Technique

1K
How To Prioritise Requirements With The MoSCoW Technique

Introduction

On most projects, we talk about requirements and features that are either in scope or out of scope. But to manage those requirements effectively we also have to prioritise them. And this is where the MoSCoW technique comes in.

Let me explain what M, S, C, and W stand for.

  • M is a must-have requirement. Something that’s essential to the project and that’s not negotiable.
  • is a should-have requirement. Something we need in the project if at all possible.
  • stands for could-have. Something that’s nice to have in case we have extra time and budget.
  • W is a will not have requirement. Something that’s out of scope, at least this time around.
    MOSCOW explanation

Why to use MoSCoW technique for requirement prioritization?

Using the MoSCoW technique gives us a more granular view of what is in or out of scope of the project, and it helps us deliver the most important requirements to the customer first. In other words, it helps you to manage your client’s expectations. And as you will come to see, the MoSCoW technique can also be used to delegate work and to be explicit about what needs to get done and what doesn't need to get done.
Why MOSCOW techniqueWhenever I train people in the fundamentals of project management, I always teach them the MoSCoW technique. And without a fail, it ends up being one of the most useful techniques, due to its applicability and simplicity. It can even be used outside of the project space. And, if you still wonder how we arrived at MoSCoW, then we’ve simply added two o’s to turn the four letters into a memorable city name.

How to use MoSCoW technique for requirement prioritization?

Let us look at an example of how to use the technique in practice. I would like you to imagine that your job is to project manage an upcoming conference. This is a yearly conference where delegates will come to network and to hear industry experts talk about sustainability in project management.
MOSCOW prioritizing requirementsM- Must

As you meet with the organisation behind the event, i.e. your client, you ask them what their must-have requirements are for the conference. You are curious to know everything you must deliver to them for them to be satisfied. Your client responds that the event must be held at an indoor venue within five kilometres of the city centre and that it must be within the allocated budget. It must be able to host 150 people and it must have facilities to serve lunch.

S- Should

You then ask your client what there should be at the event if at all possible. They answer that you should arrange for three speakers in the morning and three speakers in the afternoon. All of them should be recognised within the industry, if at all possible. In addition, you should make time for the delegates to network with each other during lunch, and lunch should, ideally, be a sit down affair with hot food. Finally, each delegate should receive a goodie bag upon arrival.

C-Could

You furthermore enquire with your client what there could be at the event. i.e. what are some nice to have requirements, which you could incorporate? You’re not promising to deliver those requirements but in case you have extra time and budget you can look into it. It turns out that your client would like to have a famous sports or businessperson open the conference. But it’s not essential and only possible if budget allows. They also think that it would be nice with a panel discussion on sustainability at some point after lunch, but it isn’t essential.

W- Would

You finally ask them what there will not be at this event, i.e. which requirements are firmly out of scope. Your client answers that there will not be multiple tracks of speakers and that there will not be any alcohol served at any point during the day. They also specify that this year there won’t be a second day of in depth workshops taking place.
Using the MoSCoW technique in this way to categorise all the project’s requirements is a very user-friendly method, which your client will be able to easily understand. Initially your client may say that everything is a must-have requirement, but when you explain that must-have requirements come with a price-tag they will understand that they can’t have everything unless they increase the budget and give you more time to deliver it.

When you plan your project, and put together the project plan, only include the must-have and should-have items. This is what you’re promising to deliver. You’re not promising to deliver the could-have items. They can go on a separate wish list. Also take care to properly document the will-not-have requirements. You may think that you can forget about them because they are out of scope. But, it’s necessary to document them as you may have to refer back to them later.

An example of using the MoSCoW technique to describe features of a requirement

What I really like about the MoSCoW technique is that you can also use it at a more detailed level to describe the features of a requirement. Let’s say for example that you have delegated the goodie-bag-task to one of your team members. That’s the little bag each participant will receive when they arrive at the venue and which normally contains a few freebies. It’s the team member’s job to gather the detailed requirements for the goodie-bag and to physically produce it.

As you’re delegating the task, the team members would like to know what your expectations are and what they must deliver to you at the end. You should explain them all the information required clearly, such as:

  • The requirements (M):
    There must be 150 goodie bags
    Each bag must contain a copy of the event programme and
    Bag as well as the event programme must be made out of recyclable materials

  • The deliverables (S):
    There should be two free branded items inside, such as a pen and paper, if at all possible.

  • Furthermore, explain that (C):
    The bag could contain something sweet, like mints, but only if a suitable sponsor is found.
    The bag could also contain a small bottle of water as a nice to have.

  • Finally specify that (W):
    The bags will not contain any alcohol and that the combined weight will not be more than one kg.

Whose responsibility is to prioritize?
MOSCOW Prioritize responsibilityBusiness Analysts are mainly responsible to take up the most complex requirements and break down them into simple tasks that can be implemented by anyone. But, BA alone can’t do the prioritization alone. He/she needs to bring in several stakeholders  into the process and get their approval on the requirements priority. It is essential for BA to understand the dependencies between the requirements before prioritizing them.

Benefits of using MoSCoW technique for Business Analysts

The BA can make use of any prioritization techniques to prioritize the requirements thoroughly. But, MoSCoW technique is the effective one to use among all the other prioritization techniques available. Some of the benefits of using MoSCoW technique for Business Analysts is shown in the figure below.
MOSCOW BenefitsConclusion
As we can see that we can prioritise requirements with MoSCoW technique at a high level but also at a low level to specify the detailed requirements, or features, of a product. When you use it at a low level it also helps you to delegate tasks better to team members and to set expectations. Are you ready to give it a go?

Susanne

Susanne Madsen

Blog author

Susanne Madsen is an internationally recognised project leadership coach, trainer and consultant. She is the author of The Project Management Coaching Workbook and The Power of Project Leadership. Working with organisations globally she helps project managers step up and become better leaders.

Prior to setting up her own business, Susanne worked for almost 20 years in the corporate sector leading high-profile programmes of up to $30 million for organisations such as Standard Bank, Citigroup and JPMorgan Chase. She is a fully qualified Corporate and Executive coach, accredited by DISC and a regular contributor to the Association for Project Management (APM).

Susanne is also the co-founded The Project Leadership Institute, which is dedicated to building authentic project leaders by engaging the heart, the soul and the mind.

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Must-have tools for Seamless Agile Management

For a long time, developers did not have a lot of freedom with their projects when it came to product development. Expected to work within the restraints provided by the top management or the sponsor of the project, and creatively limited by locked plans, developers craved to think out of the box and unleash their intuition and skills to develop a much more productive system.  This led to the rise of Agile development, a methodology that allows developers to be flexible and creative in delivering exactly what users demand. Agile management took over a whole new system of development. This management system has come a long way since its birth and has now become one of the best manifestos for project management.   However, with such a heavy structure in place, there were strenuous tasks and methods involved. To get accustomed to this manifesto, you should invest in a good Agile and Scrum certification to get well versed with the different Agile tools given below: Agile Manager This tool helps organize and guide teams from the start as they work towards developing working code for an Agile model. At the beginning of this process, the manager will gather important user stories and contemplate on how to attack the problems addressed by them.  During each code sprint, the developers record their progress on user stories and their problems. The entire progress is plotted on a dashboard so that everyone is up to date with their work. Agile Manager dashboardThe Agile Manager offers many features: Creates epics and map them to releases, features and stories Uses story points for estimation Analyses sprint performance with help of dashboard and scrum Uses templates and custom statuses for process management JIRA The JIRA tool is one of the best tools for project management. The team first makes a list of project tasks with the help of a tool called Confluence. Then they track the tasks on an interactive Kanban board that developers can update as they finish each task.  This Agile tool is integrated with other tools. Bamboo is a tool that offers continuous integration that pre-builds the code before evaluating it. Discussions take place through HipChat, and these revolve around the tasks and probable solutions.  Jira dashboardMain features offered in JIRA include: Issue tracking Boards Epics Bug tracking Custom fields Planbox Planbox is a hierarchical tool. It offers four specific levels of organizational power, thus allowing many teams to simultaneously work towards a single goal. The topmost level is called the initiative, which is broad and abstract. They contain various projects, which are filled with tasks. Planbox creates these projects and evaluates them to form a report. This report is prepared for the shareholders.  There are various amazing features like looping customer reviews and time tracking. This tool is integrated with Github for storage and Zendesk for tracking customer satisfaction.Planbox dashboardLeanKitLeankit is a very unique tool. It aims to create a conference room type of whiteboard where most projects start from. This lets members post virtual notes on it that represent tasks, user stories or glitches, which should be addressed later.   The board has a fast update feature and lets multiple teams work together in separate spaces while still coordinating together.  Leankit dashboardThe key features offered by Leankit are:Board view templates Track issues and bugs Manage project portfolios Lean metrics and reporting Proggio This is a next generation project management tool which focuses on and around the team instead of the task. It has a good visual representation that allows managers to create a full-project blueprint. This promises team clarity and increased planning capabilities.With the powerful task management tool, every team member is sure to be on track, and the virtual portfolio is an added accessory that helps tabulate developer progress.  Now, chasing around team members for every update is no longer necessary! Any and all progress report by the team members will clearly be reflected in the project timeline.  Proggio dashbarodThey main features offered by Proggio include: Board and List views Visual tracking Better timelines Choose the Agile tool best suited for your business In this vast market, there are unlimited tools created for Agile, but the above-mentioned are the ones which yield the best results. This will help you evaluate and find the tool that functions best for your context and is comfortable for your team. With every team applying their unique approach to the Agile methodology, choosing the right tool may appear to be a rather difficult task. However, once the Agile manifesto is in place, things are sure to run quite smoothly and profitably.  Be sure to check our our latest course schedules for Agile and Scrum and take strides ahead with your professional growth in Agile.
Rated 4.0/5 based on 14 customer reviews
6576
Must-have tools for Seamless Agile Management

For a long time, developers did not have a lot of ... Read More

How to Use Scrum Board for Agile Development

What is a Scrum Board?A Scrum Board or an Agile Board is a visual representation of the work planned, progressed, and completed by a scrum team in a sprint or iteration at any given point of time. The board is comprised of columns that represent various successive states of the workflow progressing from left to right. The work items appear in the column as per their current state in the development workflow and then move across the board from one column to the next till they reach completion or last stage.The “To Do / Ready” and “Done” states appear in almost every Scrum Board, the “In Progress” items can be further categorized into various states e.g. – Analyse, Design, Code, Test etc. These states are solely created as per the needs of the Scrum Team and Project.Image 1: Simple Scrum BoardWhy is a Scrum Board needed? The Scrum Board visually represents the amount of work along with their current states in a Sprint.  The Board speaks to the team everyday about the holistic progress made by the entire team towards their Sprint Goals and provides a sense of accomplishment and achievement when work items are completed. It avoids creation and progress of “Hidden Work” or “Shoulder Tap” injected work that may not be prioritized. In the event of an interruption (like production issue, any new or changed requirements, changed priorities), it helps Business to reprioritize the work items quickly looking at the current state of the planned items in the Sprint.   It also keeps reinforcing road blocks and impediments faced by the team to all the major stakeholders. Any number of written and verbal communication may not be able to visually represent the state of the entire sprintas a whole as effectively as this visual radiator.Scrum board allows teams to manage the flow of work across the sprint as it helps in avoiding multi-tasking, overloading one person because everything is visible and traceable. How to organize a Scrum Board Physical and Virtual Scrum Boards Teams that are entirely collocated can benefit from physical boards that caneven just be a whiteboard placed near their work cubicles. A physical board could also be on a wall having coloured tape for columns and sticky notes for cards.  Team members typically swarm around the board /agile wall/task wallduring their daily stand up or whenever there is a need. Image 2: A typical physical scrum boardImage 3: A typical Jira scrum boardDistributed teams on the other hand find virtual boards easy to use. There are many tools available in the market to set up Scrum Boardssuch asJira , Rally , Monday.com etc.  In some companies, the Scrum boards are displayed on giant monitors placed near the teams work cubicles. Cards and Columns are the two basic entities on the scrum board.Card is the entity on the board that represents a “Work Item”. A Card can be a User story /Production Bug/Technical Task. During the course of the Sprint these cards travel through the board from left ,“To-Do” to right “Done”.  A Simple Scrum Board for Beginner Teams The Scrum Board below is an example of a typical team board in a software project. Image 4: Typical scrum board for a software projectThe items on the Product Backlog are discussed and as per priority and their readiness, pulled into the “To Do” or “Ready” column during Sprint Planning. At the beginning of a Sprint all items in the “To Do” or “Ready” column comprises the Sprint Backlog of the team. As the Sprint progresses, the items move into the downstream columns until “Done” is reached. A clear “Definition of Done” helps to conclude if the story / task is completed. Usually beginner teams build the board translating the current workflow of their work items into columns on the board. As the teams evolve, they adjust the board accordingly. Effective Visual Representation of data  Information on the Cards Physical Cards usually are post-it notes or sticky notes that carry the User Story/Description, Acceptance Criteria and the Story Points as a minimum. Using post-it notes is a deliberate attempt to keep the story small and avoid loading a lot of work into one story.  In a Virtual board, cards can have exclusive fields to carry information like Project Name/Assignee/Reporter/Created Date etc. These might serve multiple purposes like metrics/reports. Colour-Coded Cards Colour coding is an excellent technique used to convey important information to the audience at the first quick glance.Cards can be colour coded based on their work type like User Story/ Technical Task/Production Bugs. Cards could also be flagged (in the case of a Virtual board) or overlaid with a (preferably) Red coloured card to convey a risk/dependency that needs attention. Swim lanes Defining Swim lanes is a very useful mechanism to categorize the work items on a Scrum Board. They are horizontal rows on the board that carry a specific type of work that is different from the normal/ work categorized by a certain parameter. For e.g. a team that has to resolve emerging high priority production bugs would prefer to use a “Fast Track” swim lane to progress the bug and then continue with their original Sprint work. A team that works on hardware, firmware and software components in a sprint might want to use different swim lanes for each component.  Swim lanes are for the teams. Creating a swim lane for each team member may not be a good idea since the basic guideline for scrum is to work as a team and this representation might affect a team’s mindset. In the board below blue cards are User Stories and green Cards are tasks. Red cards are Production bugs. Some cards are flagged red indicating risks or impediments. Image 5: Example of scrum board with colour-coded cards and swim lanesAspects of Kanban in Scrum BoardA common challenge encountered in projects is when tasks accumulate or pile up in a phase or stage of the workflow. There could be several reasons why that happens. But identifying them is the key to solving that challenge and the Scrum Board effectively helps in this. Assume that Cards D, E, F, G have completed development and ready for testing. Cards B, C are being tested. It is day 6 of a 10-day Sprint.  Developers might now bring in H, I from the Ready Column to start development work, creating a bottleneck at Testing. Image 6: Scrum Board without WIP LimitsConcepts of Kanban can be borrowed into a typical Scrum board to address this. One of the techniques that can be used is to split the column into “In Progress” and “Ready”. This will set the stage for a “Pull” mechanism at every stage in the workflow of a story.  Introducing “WIP Limit” or “Work in Progress” Limit at the columns ensures multiple work items do not pile up at one stage of the process, do not get “pushed” downstream but rather gets “pulled” by downstream process and there is a steady flow created in the system. Considering the team is at day 6 of the iteration, it is recommended the team “stops starting and starts finishing”.  If the team swarms and completes the testing of D, E,F,G there could  be more business value delivered rather than starting development of H and I and having only few of the Development complete cards partially tested. In this scenario, a WIP Limit of 4 at development prevents the team from bringing in more work items into the development phase. The team can now swarm to complete the testing of the developed items taking them to completion.  Image 7: Scrum board with WIP limits and columns split into “In progress” and “Ready”Effective use ofthe Scrum Board  Updating and maintaining the Scrum Board Scrum board is owned by the team and it is the team’s responsibility to update the board to reflect the reality.The team also has the responsibility to evolve the board to suit the need of the project by experimenting on concepts of WIP Limit. How best to use the information on the Board Scrum Board can be used to identify bottlenecks in the flow of work. If bottlenecks are identified in one stage of the workflow, the team can resort to Swarming or enforcing WIP Limits. Seeing the work items move through the Scrum board and reach “Done” during the Sprint provides the team a sense of accomplishment. Challenges and ways to overcome them Easier said than done, updating the board is one of the biggest challenges faced especially in beginner teams. Not every team member will be prompt in updating the board. To overcome this challenge, updating the board could be one of the team ground rules with non-compliance attracting fun consequences decided by the team, such as the defaulter treating the team with chocolates/coffee or updating everyone’s scrum board the next day. The Scrum Master can immensely help the team realize the power of the board by using it during agile ceremonies like planning, stand up and retrospectives. Facilitating the scrum by traversing the board from right to left (i.e.“Done” to “To-Do”) is another tactic to keep reinforcing the value of the board and motivating the teams.Having conversations in stand-ups by traversing the board from right to left will first bring up cards that are done or almost done and helps see what has been accomplished in the sprint.  What a Scrum Board is not A Scrum Board cannot replace the conversations and interactions that are always encouraged in Agile projects. Flagging a card on the scrum board / posing queries on a card should not solely replace the conversations around these. A Scrum Board is not for executives to monitor the team’s progress and efficiency, but it is for the team to monitor their sprint items as a whole. Key takeaway A Scrum Board is an excellent tool for the team to visualize their work, look at everyday progress, identify bottlenecks, make immediate course corrections, so that they can meet their Sprint goals. Used rightly, it will serve the team and benefit them. However, if it is used by management to monitor the team or if the team members consider it as a tool to update management then it loses its purpose and becomes just another overhead. 
Rated 4.0/5 based on 13 customer reviews
6649
How to Use Scrum Board for Agile Development

What is a Scrum Board?A Scrum Board or an Agile Bo... Read More

Scrum Master Job Descriptions and Responsibilities In Agile

Scrum stands out as one of the most dominant Agile frameworks used widely across the world. As per the ‘14th Annual State of Agile Report’ published by VersionOne, Scrum has 58% of the segment in the overall adoption of frameworks across the organizations globally. Not only has Scrum captured a large share in the industry, but it is also easy to implement and brings about a more collaborative approach.   Scrum has three roles: product owner, scrum master and the development team members. It is these three roles that define the way a team works towards a single goal. Of the three roles, the role of the Scrum Master will be the focus of this article. We will talk about the qualities that make a successful Scrum master stand out from the crowd and discuss the major skill sets that employers seek from Scrum masters. Later, we will delve into how best to prepare for this role and how necessary it is for a Scrum master to possess technical knowledge related to the product or technology the team is working on. Finally, we will address how a Scrum Master can accelerate change and positively impact delivery in the team.  What is a Scrum Master?  Scrum Masters are facilitators of Scrum who act as servant leaders to drive the delivery in terms of process and product. As facilitators, scrum masters act as coaches to the rest of the team, “servant leaders” as the Scrum Guide puts it. Good scrum masters are committed to the scrum foundation and values, but remain flexible and open to opportunities for the team to improve their workflow. The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. They do this by helping the team and the management understand the theory, practices, rules, and values of Scrum.  Roles of a Scrum Master  The scrum master is the role responsible for glueing everything together and ensuring that scrum is being done well. In practical terms, that means they help the product owner define value, the development team deliver the value, and the scrum team to get better. The scrum master is a servant leader which not only describes a supportive style of leadership but describes what they do on a day-to-day basis. The several ways that a Scrum master services the product owner, the Scrum Team and the organization are elaborated below. Service to the Product Owner Ensures that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible. Finding techniques for effective Product Backlog management. Helping the Scrum Team understand the need for clear and concise Product Backlog items. Understanding product planning in an empirical environment. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value. Understanding and practicing agility. Facilitating Scrum events as requested or needed. Service to the Development Team Coaching the Development Team in self-organization and cross-functionality. Helping the Development Team to create high-value products. Removing impediments to the Development Team’s progress. Facilitating Scrum events as requested or needed. Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. Service to the Organization Leading and coaching the organization in its Scrum adoption. Planning Scrum implementations within the organization. Helping employees and stakeholders understand and enact Scrum and empirical product development. Causing change that increases the productivity of the Scrum Team. Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. Four main stances of a Scrum Master The Scrum Master wears different hats to deliver results.  As a Facilitator The Scrum Master is a facilitator who makes sure the team is following the scrum events by serving and empowering the team in achieving their objectives. The person must be ‘neutral’ without taking sides in any conversation or meeting, at the same time, back everyone to do their best in intellectual and in practice. On the lines of facilitation, Lyssa Adkins provides a very apt statement:   A Scrum Master should facilitate by creating a "container" for the team to fill up with their ideas and innovations. The container, often a set of agenda questions or some other lightweight (and flexible) structure, gives the team just enough of a frame to stay on their purpose and promotes an environment for richer interaction, a place where fantastic ideas can be heard. The coach creates the container; the team creates the content. - Lyssa Adkins As a Coach The Scrum Master helps the team to understand the framework and accordingly coaches them for being self-organized and cross-functional. This person inspires an outlook of continuous improvement and Back the team in problem-solving and conflict resolution.   As a Servant Leader The term Servant Leader was originated by Robert K. Greenleaf, who described this term as “The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. - Robert K. Greenleaf  This person ‘leads by example’ and puts the team/individuals' needs on priority. They make sure they are setting the foundation of trust, honesty, transparency, and openness. At the same time, they are the leader whom the team can look up to.   As a Change Agent The scrum Master brings about the change in terms of process, practices, and ways of working. They act as a catalyst in the overall transformation to bring about the degree of change expected from an organization. They help the team follow the process along with helping the stakeholders understand the empirical process. They help the entire team to adopt processes and enhance the delivery.  Scrum myth: The scrum master must run the daily scrum. In fact, the scrum master does not run any of the events, just ensures they happen and that they are successful. Top Qualities of a Successful Scrum Master  As with other roles, there is a secret sauce that goes into making the Scrum Master successful. While every individual serving as a Scrum Master may bring along their own personalities and strengths to reinforce the role, there are a couple of must-have qualities which every individual donning the Scrum Master role must hone. Let’s take a quick look at these traits that can add a pinch of charm to the Scrum Master role.  Powerful communicator The Scrum Master needs to be very specific and clear on the communication they have with the team and with stakeholders. They must be aware of the right channels and when to use them. They should know how to influence teams for better results.  Inspires ownership A good Scrum Master helps the team to understand Agile principles and why the team can gain better results through the adoption of ownership. They help the team to take ownership of their tasks, their task board, process, and even small failures.  Reads the room The Scrum Master should be able to understand and sense the temperature of the room. They should know when conflict is cropping up and how to deal with it smartly. This helps to build a culture of trust and transparency amongst the teams.  Impartial The Scrum Master can become a star leader if they are neutral towards any situation or the individual. They focus on the problem rather on the individual. They know every individual is good and has the right intentions, it is just the situations that alter the way the team behaves. This not only helps in creating a rapport but also gives one the satisfaction of doing the right thing.   Scrum Master Job Description and Responsibilities  With the increase in demand for Scrum Masters globally, it is important to understand the job description. Every industry is different and so are their ways of working. While each organization may have their own versions of the job description for a Scrum Master as per their need in a project, we will take a closer look into the typical job description that organizations use.   Below are some of the common points you will usually find in an open position for a Scrum Master:  Standups: Organize daily stand-up meetings, facilitate, and plan other project meetings as required including demos as suitable.  Sprint reviews: Empower the team to become self-organized to consistently deliver on their sprint commitments.  Adoption of best practices: Ensure development teams enthusiastically apply core agile principles of collaboration, prioritization, accountability, and visibility.  Impediment removal: Responsible to address impediments that prevent successful development and testing of approved requirements.  Visualization of issues: Support team to detect barriers that prevent it from delivering features to the customers.  Agile master: Strong knowledge of Scrum philosophy, rules, practices, and other frameworks.  Understanding of the software development process: Familiarity with software development processes and measures to understand team requirements.  Process ownership: Harmonize scrum team with agile; collaborate with Leadership to ensure delivery teams practice Agile framework and software engineering best practices.  Stakeholder management: Work in partnership with Stakeholders, Product Managers, Business Analysts, and development managers to plan releases and manage a healthy product backlog  Metrics/reports: Endorse and present appropriate metrics to sustain continuous improvement to get the best out of each team. Report progress, team status, and issues across the board.  Transparency: Communicate development status to sponsors, participants, management, and teams. Shares weekly or bi-weekly reports to ensure everyone understands the current state.   Quality: Safeguard observance of quality standards and project deliverables. Understand principles to drive quality ethics and help in devising tools and practices for best end results.   How can I prepare for this role?  Donning the role of a Scrum Master is akin to heeding to an internal calling; the role requires a person to be patient, a good communicator, a good listener, and most of all emotionally intelligent. If you want to become a Scrum Master, make sure you understand the in-depth meaning of servant leadership. It is not just following the process and events that make up a Scrum Master, it is a huge role which requires leadership while serving the team. If this is your calling, then here are some steps you can take –   Start learning about Scrum and how effectively you can use its values and principles with your team  Start reading articles and blogs on best practices with success stories.  Prepare for the certification required to start your journey.  Make sure you have a mentor who can shape you well and can help you hone your skills  Continuously work on your communication and influencing skills.  Is it essential for a Scrum Master to possess technical knowledge?  Of late, we have started noticing many job postings where organizations specifically demand a Scrum Master who is technically sound and knows the in and out of the technology the team is working on. Traditionally, however, Scrum Master is a non-technical role where the focus is on improving the work culture, adopting Scrum/Agile and its best practices, and helping the teams to grow, become self-organized and high performing. While it is a good-to-have criterion, technical knowledge is not mandatory. But then again, it really depends on the organization and their need.  Get started with the Scrum Master role  If you want to help teams work effectively together and want to change the world with scrum and agile, then the scrum master role is for you. It is a very people-centric role with a heavy emphasis on coaching, teaching, and facilitation. The Scrum Master role can be a game-changer for project delivery. They help the team understand their true potential which most of the times teams themselves are not aware of, with the help of coaching, mentoring, and using engaging team activities that help in understanding the overall process and delivery.  The Scrum Master role is critical and needs to be handled with care as the stakes are high. This role has a high degree of accountability and responsibility towards the team, process, and organization which not only requires an open mindset but also a concern for the wellbeing of co-workers.  Lived to its full potential, this role can build awesome high-performing teams that sustain hardships and efficiently draw learning out of every experience. Such teams are bound to succeed at every step, taking even failure as a step towards success. 
Rated 4.5/5 based on 20 customer reviews
29770
Scrum Master Job Descriptions and Responsibilities...

Scrum stands out as one of the most dominant A... Read More

Useful links