Kickstart your career with best deals on top training courses NY10 Click to Copy

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

578
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

Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Product Backlog Grooming, is a method for keeping the backlog updated, clean and orderly. It is a basic process in Scrum. PBR is a collaborative discussion process which starts at the end of one sprint to confirm whether the backlog is ready for the next sprint. Backlog can be defined as a set of user stories which are not present in the current sprint that defines project’s scope context. The stories which are left unattended, may interfere with the functioning of the development team.When this happens, the status of user stories will not be clear, and even the team can lose focus and fail to deliver within the project completion date. The backlog grooming meeting is attended by the scrum master, who facilitates everything for team members, the team and the product owner. They decide among the top items from the product backlog. The team comprises mainly of Developers, testers and Scrum Masters. The team can raise queries during the sprint planning session if they find any unresolved issue. The expected doubts can arise in the following forms : How to handle the situation if the user enters invalid data? Which part of the system are the users authorized to operate on? For the product owner, it will be easy to get the conclusion over the queries, by asking these questions in the early stages. If there is a question which is unanswered by too many people, it is time to make some changes in your backlog items by curating higher priority items to the top of the list and assigning highest priority to the unanswered questions. The Objective of PBR meeting: A lot of time is saved at sprint planning meetings, if the backlogs are well maintained. If the backlog item is clearly specified in the acceptance criteria and cross-checked properly by the team members, the planning process can be accomplished prior to the meeting. PBR offers the team members the opportunity to interact with each other regarding stories. Why is PBR important?  PBR and its sessions are important mainly due to the following features- It increases the efficiency of the team by reducing uncertainty Properly refined stories are easy to estimate, test and implement. PBR session increases the efficiency of the team due to the knowledge shared among the team members. If PBR meeting is maintained properly, it helps reduce the time for a Sprint planning meeting. The Product Backlog grooming can be made effective if the following aspects are considered- Do not schedule backlog refinement meeting during the first and last 20% of the Sprint Planning session. Backlog refinement meeting should be considered as the first part of Sprint Planning. The backlog items’ list should be well understood by the PO, or development team member to work well in the meeting. Make sure that the set of predefined acceptance tests are present. Keep an eye on the meeting goals. Make sure to assign action items for any unknown thing. Do remember that the backlog items are a collaboration between the PO and the team. Feel free to break the product backlog items during the meeting. After the product backlog refinement meeting, the team can update the Product Backlog items in line, based on the discussions held. Finally, you can get a potentially shippable product, ready to be deployed in the market.
Rated 4.0/5 based on 20 customer reviews
2419
Product Backlog Refinement in Scrum

Product Backlog Refinement, also referred to as Pr... Read More

Writing Effective User Stories in JIRA

User stories are one of the main methods of communicating requirements to developers/development team in an Agile project. It is important for the individual tasked with documenting the requirements to be able to write effective and detailed enough user stories. The user stories are required to be comprehensive enough to enable the developer/development team to start analyzing, designing and developing the required functionality, feature or requirement stated in the user story.     This article while intending to guide individuals on how to write effective user stories is also intended to advise on the best practices of creating user stories using JIRA as a requirements management tool for creating stories and tasks. What is a User Story?   User stories are short, simple descriptions of a feature in the system under development told from the perspective of the person who desires this new capability. This person is normally a user of the system or even a customer who pays for the solution.  User stories typically follow a simple template as below. As a , I must be able to so that I can .  User stories are often written on index cards or sticky notes and pasted on an information radiator or in other words a scrum board. This article is however on maintaining user stories using JIRA and on how the tool can be used to ensure regular conversation.  Writing user stories on an index card is actually the ‘Card’ part of the 3 C’s in user stories. It is said that a user story should be long enough to fit into an index card and be detailed enough to arouse discussion. Writing user stories in JIRA A new user story in JIRA can be created by selecting the option to create a new issue of type ‘Story’ as shown below.  The user story in the format listed above can be written in the summary field of the new issue creation screen.  User story definition should satisfy the INVEST criteria which implies that the user stories should be: Independent (of all other user stories and be able to exist on its own) Negotiable (not a specific contract for features but be able to be used to facilitate discussion among relevant stakeholders) Valuable (create some business value) Estimable (to a good approximation) Small (so as to fit within an iteration) Testable (in principle, even if there isn’t a test for it yet)   Trace your Customer Requirements to user stories in Agile through the integration with JIRA. https://t.co/esXyAJykZy pic.twitter.com/DZoa1tJrjL — Visure Solutions (@VisureSolutions) 21 November 2017   JIRA also provides the option to set priority of user stories which might have been done based on the MoSCoW criteria, due dates, assign the story to a team member of the project, allocate a story point/hour based effort estimation for the story, tag the user story to a component level feature or in other words ‘Epic’ and be able to assign the story to a sprint during which the story is required to be implemented. Adding description to user stories The 2nd C of the 3 C’s in user stories that is ‘Confirmation’ is used to specify the acceptance criteria of the user story. An acceptance criterion is used to ascertain when a particular user story can be marked as done and is normally used by the product owner to validate the same. The acceptance criteria also help the development team implement the business rules, functionality and will be the single point of reference for the Quality Assurance Team. The description field in JIRA issue creation provides space for the user to specify the acceptance criteria.   Gearset’s Jira Self-hosted (on-prem) and Jira Cloud integration lets you automatically post deployment updates to your tickets & keep up-to-date with the progress of your user stories. https://t.co/qvDlNK5LLr pic.twitter.com/yh8RmUL1Gm — Gearset (@GearsetHQ) 29 January 2018 Enabling discussion Another main aspect of writing requirements as user stories is to enable conversation about the feature among relevant stakeholders. This is known as the ‘Conversation’ component of user stories which is the 3rd C in the 3C’s.  Often user stories are accompanied with a process diagram, UI wireframe or a mockup, data dictionary etc. which can be added as attachments in JIRA or even be associated with the story as comments, wiki page links maintained in confluence. Conclusion Writing user stories is an easy method of maintaining requirements in a dynamic environment of an Agile project. JIRA, as explained above, provides a powerful and rich set of features which helps manage requirements in an efficient and convenient manner.    
Rated 4.0/5 based on 1 customer reviews
3659
Writing Effective User Stories in JIRA

User stories are one of the main methods of commun... Read More

12 Common Mistakes Of The Scrum Master And The Remedies 

Today, companies are becoming a part of the massive technological leapfrogging through some of the popular Agile methodologies. When we talk about Agile, people think of “Scrum” naturally. Scrum is the most widely used framework among the popular organizations. These organizations leverage Agile and Scrum methods for a disciplined project management practice, as Agile encourages continual feedback, iterative development, rapid and high-quality delivery and iterative development.                                         “Life of the Scrum Master is full of challenges, Scrum problems, and Scrum pitfalls.” According to the “11th Annual State of Agile Report” by Version One, the following figure states the top reasons for adopting Agile and Scrum methodologies in organizations. The concept is simple but difficult to implement. Being a Scrum Master can be a tough task, if unaware of the Scrum Master’s skills. Here are the most common mistakes of the Scrum Master and the solutions while implementing a Scrum framework: Look out for these 10 common #scrum mistakes with some simple tips: https://t.co/asOR8ZVj00 #agile #lean #scrummaster #devops pic.twitter.com/WUxQHtKhW5 — TO THE NEW (@TOTHENEW) 29 November 2017   1.Scrum Master acting as a Project Manager- In the Agile methodology, companies follow the “Daily Scrums”. Before starting the day’s work, teams gather around the board to discuss the current and the preceding days’ tasks. Usually, team members report on ‘what they did yesterday’, and wait for the Scrum Master’s reply on ‘which task to do today’, instead of self-organizing within the team.   This is where the Scrum Master makes a mistake. He is acting as a Manager, not as a Scrum Master. A Scrum Master should ideally make team members ask ‘what should be finished next?’      2.Scrum Master making decisions for the Team-     In most of the organizations, Scrum Masters are recruited by practical experience (generally senior developers and the project leads are given priority) and by personality in terms of communication skills and the sound mind to carry out decisions to keep the project processes on track. Due to this, team members rely on the Scrum Master for each and every decision, which is totally wrong.  Most of the times, teams consist of a variety of different personalities and letting them express their opinions can help to deliver the best. Avoid dictatorship, as it affects the team spirit, stifles progress and results in a lack of communication among the team members. This is one of the common Scrum pitfalls a Scrum Master typically faces during work.   3.Scrum Master holding sole responsibility for the delivery-   This is the common Scrum problem usually found in traditional companies, that have recently entered in the world of Agile development. In traditional companies, people were so far following the leadership style viz. ‘Command-and-control’, in which a single person used to be accountable for all the project tasks, making management impediments-free, simple, and more comforting.  Normally, Scrum Master ensures that the developers are inclined to all the project requirements. But when it comes to the responsibility of the Scrum Master to deliver the product, he/she just concentrates on the product delivery, ignoring the quality. To avoid this, stop planning projects individually. Planning is collectively done by the team members. It needs each and every team member to adhere to the commitments, to understand the target and the way to achieve that.   4.Scrum Master acting as a mediator between the Team and the Product Owner-   Suppose the team has finished with the daily Scrum and started to construct a functionality which was recently planned for the meeting. But the team is facing some difficulties and needs to discuss with the Product Owner to get an information. At this point, the Scrum Master communicates with the Product Owner to remove communication barriers and furnishes the needs of the team members. After asking the relevant queries to the Product Owner, the Scrum Master relays the same to the team.     In this way, Scrum Master acts as a mediator between the team members and the Product Owner and forms a Scrum solution to overcome communication impediments.   5. Not conducting Retrospectives after every Sprint- One of the principles from the Agile Manifesto states that- “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Sprint Retrospective is often considered as an add-on, and implemented only in free time. Agile is all about the adjustments, fine-tuning and versatility. It is really very difficult to fine tune if you seek for the adjustments every time. 6. Not removing obstacles at an initial stage- One of the main roles of the Scrum Master is to remove the impediments. The daily stand-ups is the best way to communicate the obstacles to get the task done. But in case these barriers (more correctly, the issues or constraints) are not escalated by the team members, Scrum Master will fail to remove them. Scrum Master should remind the team at the very beginning to present the potential blockades which might delay their work.     So, at the end, you can have several SMs for a team if your combination allows to get the team focused on delivering value and not wasting time on who is the Scrum Master that can help them on removing impediments or facilitating events. — Israel López (@israelagile) 27 November 2017     7. Less/ No daily stand-ups-   The daily scrum is pivotal from several aspects. It allows open communication (face-to-face), collaboration, yields visibility and transparency into the project. So, for every team member, attendance should be mandatory. During meeting, each team member should stick to the following 3 questions-  What did I accomplish yesterday? What will I work on today? What impediments are blocking me in achieving the project goals? It should, however, be noted that the teams do not have to restrict themselves to the above three questions. As per the tenets presented in the latest Scrum guide, discussion-based stand-ups are equally effective and provide insights into the latest happenings in the Scrum team.   Scrum Master Daily stand-ups https://t.co/vlORxTcJoV — Kevin Ackerman (@ackwdw123) 15 June 2017   8. Not strictly adhering to the Agile Manifesto principles- Try to keep Agile startups uncomplicated. According to Agile Manifesto- Agile gives higher value on  ‘individuals and interactions than on processes and tools’. So, Agile projects can be successful without the use of the tools. You can use stickers on the wall, spreadsheets, and manual burndown charts to keep the process simple.   12 #Principles of the Agile #Manifesto by the @AgileAlliance People matters. We are in the ages of uncertainty at work. We need our minds to boost the best of us and businesses #ProjectManagement #teamwork #SustainableDevelopment pic.twitter.com/4yFAOitEYC — Anca Fajardo (@KathiFajardo) 20 January 2018   9. Wrongly assuming an easy transition to Agile- Agile transformation takes time to set up in the organization. It always starts with mess-ups. Transformation includes dealing with the existing corporate and cultural problems like- poor communication, lack of accountability, skeptics, time management, etc. Effective Agile transformation can be a total cultural change. Be patient and ready to embrace the cultural changes. A company's transition to an Agile environment is a welcome and positive experience. But when reality sets in, some resist the change, particularly those in management. https://t.co/kxpyWqBcUB — Joe Little (@jhlittle) 21 January 2018   10. An ill-formed/non-prioritized product backlog- The most common reason behind Sprint failure is a product backlog with status “not ready”. It is also a cause for delivering low value. Making a backlog ready before the ‘next sprint’ is good. Do not let the team run out of the tasks and keep in mind that every task should be prioritized by the Product Owner.Always heed the point that being a Product Owner or a Scrum Master can be time consuming.So set the goals and provide the necessary training on product backlog to the team members.  What's in a Product Backlog? The most critical part of any Scrum project is a well-defined product backlog. How do we effectively define an efficient and productive backlog?https://t.co/QqMyGe9MBm — Dan Tousignant (@ScrumDan) 19 January 2018   11. Not handing over the ownership of daily scrums to the team-  Sometimes, Scrum team keeps some of the product backlog items undone. This results in spilling over of the undone tasks and simply shifting to the next sprint. This happens when a team fails to finish the high-priority tasks. However, Scrum Master and the team should not take it lightly. When they do this, Sprint planning become meaningless. Therefore it is mandatory on the part of a Scrum Master to support his/her team in planning of its next sprint so that they can finish everything on time. Equally essential is to make them feel accountable if they do meet the targets and the stipulated deadlines.   Do Scrum Teams Meet Too Much? One of the most frequent criticisms I hear of Scrum when teaching Certified Scrum Master courses is “Scrum teams have too many meetings.” With daily scrums, sprint planning meetings, sprint reviews, retrospectives and https://t.co/O9t2EUsq5y — Dan Tousignant (@ScrumDan) 19 January 2018   12. Overburdening the Scrum team-  Scrum team works in Sprints. Only when one sprint ends, the next one begins. Under no circumstances should two consecutive sprints overlap. In simpler words, teams should avoid working in the upcoming sprint while the current sprint is still on. To maintain consistency, the team should work at a sustainable pace. A Scrum Master should safeguard the team from going beyond this sustainable pace and tackle any situation that might overburden the members.     Concluding Thoughts- Scrum, as you already know, is one of the largest and promising frameworks in Agile methodology. One can in fact strongly say, a paradigm shift has occurred with the advent of Scrum. It is therefore important for the companies to practise Agile in a correct way to build the products and deploy them faster to the market. Therefore, being a Scrum Master, it is pivotal to avoid the above mentioned Scrum problems to successfully launch the product in the market.
Rated 4.5/5 based on 9 customer reviews
1857
12 Common Mistakes Of The Scrum Master And The Rem...

Today, companies are becoming a part of the massiv... Read More

other Blogs