The Best in Scrum Master Certification and Agile Certification - SCRUMstudy provides High Quality Training and Certification for Agile and Scrum Master. We provide Interactive Training which covers all Project Management Roles and Core Principles.
The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is prioritization.
Prioritization can be defined as “Determination of the order and separation of what must be done now, from what needs to be done later”. The concept of prioritization is not new to project management. The traditional Waterfall model of project management proposes using multiple task prioritization tools. From the Project Manager’s point of view, prioritization is integral because certain tasks must be accomplished first to expedite the development process and achieve the project goals.
Some of the traditional techniques of task prioritization include setting deadlines for delegated tasks and using prioritization matrices. Scrum uses Value-based Prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service.
More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis. Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to fruition.
Once the Product Owner has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value.
The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance.
Prioritization results in deliverables that satisfies the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.
Well, a User Story is basically what the user is required to perform as a part of his job responsibilities. It gets the data of who, what and why pertaining to a prerequisite in a simple and conscience way on a note-card made of paper. User Stories are written by or for the business user and could also be written by the developer. User Stories are easy way of taking care of customer requirements without the need to make formal requirement document and without the need to perform tasks which are about administering and maintaining them. Faster response in a much more economical way to the dynamics of ever altering requisites of reality forms the prime intention of User story.
Basically, a User Story is a casual document of the requisites in case of absence of communication toward acceptance testing processes. An acceptance procedure needs to be transcribed by the customer for making sure through testing or any other methods for realizing the fulfillment of objectives pertaining to the user story, before its inception.
There are many benefits of using user story:
Corruption of information does not happen
Makes it easy to estimate the development effort
Needs less Maintenance
Have a close contact with the customer
User Story Format:
As a <role/persona>, I should be able to <requirement> so that <benefit>.
User Story Example:
As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.
The doors should be at least 3.34 foot wide and 7 foot tall, the pathways must have a clear way of at least 5.4 feet. Instead of having the requirement like this the user story is the service users must be able to drag the service cart anywhere in the building without any obstruction so that the service cart is used by all the occupants.
A Scrum master plays a crucial role in the implementation of Scrum on software development projects. Click here for the Challenges faced by a Scrum Master
A Scrum master is like a leg in the tripod of the Scrum team, with the other two being the product owner and the development team. The relationship of the product owner with the business representative is balanced out by the Scrum master’s relationship with the development team. The role of the Scrum master is to support the team in becoming self-organized, to remove any obstacles the team might be facing and to ensure that the Scrum methodology is being followed. However, unlike the product owner, the Scrum master does not play a management or supervisory role for the team.
The first step to being an effective Scrum master is to understand the principles of Scrum extremely well. As a part of this, a Scrum master should be well aware of what Scrum can and cannot achieve. A Scrum master must ensure that daily Scrum meetings are held and other important processes of Scrum are followed and that the team does not veer off course. It is important that a Scrum master knows how to use different tools and techniques such as tracking and value of metrics, and should have knowledge of software development process and other agile methodologies. What is even more important to become an effective Scrum master is to hone soft skills such as leadership and determination.
Adopting Scrum, especially when the team is not exposed to Scrum, can be challenging, and the change can sometimes be met with resistance. An effective Scrum master will have to work with a lot of perseverance to overcome this and help create an atmosphere in which team members will stand behind Scrum.
A Scrum master assists the team by addressing any issues or removing any hurdles that may stand in the team’s way. Possible issues could range from personality conflict to product ownership. The Scrum master facilitates the team, allowing it to self-organize and to determine the best way to deliver high value without compromising the ever-important Scrum methodology.
An effective Scrum master will strive to establish an amicable relationship between the product owner and team members. A product owner might at times be controlling and demanding. It is the Scrum master’s responsibility to be the pacifier and help the team maintain its morale and communicate effectively with the product owner to resolve any issues.
An important aspect of agile is that it places “individuals and interactions over processes and tools.” An effective Scrum master acts as a servant-leader. When managing the team, a Scrum master does not direct the team but leads by example and also serves it by removing any impediments and allowing it to decide the best way to grow and perform. Being a servant-leader also means that the Scrum master re-communicates the project vision to ensure the team is heading in the right direction. As a leader, it is also the Scrum master’s responsibility to encourage the team by offerings rewards to keep the team motivated to continuously improve.
A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK). After the Plan and Estimate phase comes the Implement phase.
This phase includes three processes related to the execution of tasks and activities—creating various deliverables, conducting Daily Standup Meetings, grooming the Product Backlog at regular intervals—to create a project’s product. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.
In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint deliverables. A Scrumboard is often used to track the work and activities being carried out. At the end of each Sprint, a product increment or deliverable is completed. The deliverable should possess all features and functionality defined in the User Stories included in the Sprint and should have been tested successfully. As the Scrum Team executes the work of creating deliverables according to the User Stories in the Product Backlog, they carry out the mitigating actions that have been defined to address any previously identified risks. The team documents any newly identified risks and mitigating actions taken. The record of project risks is a living document, continuously updated throughout the project by the team.
Conduct Daily Standup
In this process, every day a highly focused, Time-boxed meeting—referred to as the Daily Standup Meeting—is conducted. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing. Daily Standup Meetings propagate the idea that each member of the team is important and is a major contributor, which improves individual and team morale. This, along with the concept of self-organizing teams, improves overall motivation, leads to enhanced performance of the team and improves the quality of deliverables produced.
Groom Prioritized Product Backlog
In this process, the Prioritized Product Backlog is continuously updated and maintained. Remember, the Prioritized Product Backlog contains a prioritized list of project requirements written in the form of Epics, which are high-level User Stories, and is based on three primary factors: value, risk or uncertainty, and dependencies. A Prioritized Product Backlog Review Meeting may be held in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog, as appropriate. The Prioritized Product Backlog may be updated with new User Stories, new Change Requests, new Identified Risks, updated User Stories or reprioritization of existing User Stories.
Following the three processes of the Implement phase will guide effective execution of the project at hand. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Implement phase, however, it is imperative to follow the blueprints of earlier phases to produce quality deliverables.
A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK). The Release phase is the final stage of a Scrum project.
This phase includes two processes that emphasize delivering the Accepted Deliverables to the customer and identifying, documenting and internalizing the lessons learned during the project. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.
In this process, Accepted Deliverables (those that meet the Acceptance Criteria and Definition of Done) are delivered or transitioned to the relevant stakeholders. To get formal customer acceptance is critical for revenue recognition; the responsibility for obtaining it will be defined not necessarily by the Product Owner but by the company policies. This process marks the final shippable deliverable for which the project was sanctioned. As new product increments are created, they are continually integrated into prior increments, so there is a potentially shippable product available at all times throughout the project. The Product Releases should include Release Content, which consists of essential information about the deliverables that can assist the Customer Support Team, and Release Notes, which should include external or market facing shipping criteria for the product to be delivered.
In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements to be implemented in future projects. The primary responsibility of the Scrum Guidance Body is to ensure that the lessons learned in each project are not lost and are embedded in the organization. Additionally, the Scrum Guidance Body may provide expertise in various areas including Quality, HR and Scrum. When the initial Program Product Backlog or Prioritized Product Backlog are developed they are based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review, Retrospect Sprint or Retrospect Project Meetings. These items should be added to the Program Product Backlog (for the program) and Prioritized Product Backlog (for the project) as they are discovered.
Executing the two processes of the Release phase ends a project in successful fashion—one that satisfies all parties involved. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. In the Release phase, assuming all of the prior phases of the project were followed, the Scrum Team can enjoy a job well done while keeping in mind lessons learned for future projects.
Before we read about how to be an effective product owner, let us first understand who a product owner is and what he/she does. A product owner is not a separate title but is a role that can be performed by a business analyst or even a representative of an end user.
A product owner is a stakeholder who acts as an interface between the business representatives and the project team. A product owner understands the business requirements and communicates it to the team for development on behalf of the customer. A product owner is responsible for creating Prioritized Product Backlog, attending daily standup meetings, and steering the development process successfully to meet the customer’s requirements. The product owner communicates the progress of the team to the sponsor and key stakeholders. He or she also continuously refines product requirements. It is also important that a product owner has good business sense which is important while prioritizing user stories based on cost and functionality.
A product owner must be actively involved-
The test of an effective product owner is how well he/she balances the expectations of business representatives and capability of the team to deliver. There are several ways a product owner can be more effective. A common mistake product owners make is not committing enough time to understand the requirements of the Scrum Team. Product owners should be as hands-on as possible and schedule sufficient time to holding estimation workshops, planning sprints, and providing feedback for the team.
An empowered product owner nurtures an empowered team-
Customers most often expect more value to be delivered than what the team is capable of delivering or might suggest several changes that can slowdown the speed of the development team. A product owner supports his team by managing customer’s expectations so that workflow is not affected due to unreasonable expectations. A product owner allows the team to estimate the effort required to complete the product backlog items identified for a particular sprint. At the same time, a product owner motivates the team to deliver the product backlog items committed fora sprint on time.
Technical knowledge is essential-
It is also important that product owners have some technical knowledge, though he/she does not necessarily have to be a developer themselves. Since, they will be interacting with the team on a regular basis, having a technical background can serve well while resolving issues. Technical knowledge can also help a product owner bridge the gap between technical and business aspects of a project while liaising with developers and business representatives.
The fundamental Scrum processes defined in SBOK Guide by SCRUMStudy are valid for all Scrum projects, and concepts mentioned in the SBOK are sufficient for managing Scrum projects with just a few Scrum Teams, typically 1 – 3 Scrum Teams.
When we deal with large projects generally involving four or more Scrum Teams, some additional processes may be required to address the additional coordination and synchronization efforts.
Some reasons additional processes would be needed for large projects are as follows:
Increased interaction and dependencies among Scrum Teams, as complexity increases for a large project
Need for collaboration in a team of Product Owners
Need to manage conflicts, resolve issues, and set priorities among all the Scrum Teams
Requirement for specialization as some Scrum Teams may require specialized resources for specific tasks — and these particular skill sets are not needed on all Scrum Teams.
Necessity to define certain guidelines and standards that should be adhered to by all Scrum Teams (e.g., security standards within a company or legal and governmental guidelines for specific industries). These may need to be defined by the Scrum Guidance Body.
Requirement to set up an environment, or working area, for the large project, which would then be used by all Scrum Teams
Need for coordinating the outputs from several Scrum Teams to create a project release for a large project.
The definition of a large project may depend on the company and the complexity of projects undertaken. The key criterion for a project being large versus small is to have multiple Scrum Masters and/or Product Owners.
The term stakeholder creates a lot of confusion in Scrum. Usually the term is confused with the responsibilities of a Product Owner. Let us now clear all the confusion around it.
Best definition of stakeholders is that they have legitimate interest in the project and another important point to be noted is that stakeholders are not always product owners but product owners are always stakeholders.
Product owners help define the backlog the Scrum team and also help in prioritizing the work units of the Scrum Team and continually communicate the progress to the stakeholders.
Stakeholders are the purpose for which a Product or service is created in the first place. Stakeholders are the people who have certain necessities, wants and desires; thus in business terms they have certain requirements which needs to be fulfilled. It is the responsibility of the Scrum Team to fulfil the requirements of the Stakeholders and satisfy them. Usually stakeholders do not have clear understanding of what they need and even if they do they keep changing their minds very often. Usually figuring out the actual needs of a stakeholder is achieved through a lot of meetings with the stakeholders and also after a lot of trial and error.
The stakeholders are very vital to the success of the Scrum team as they keep reviewing the team’s products and progress and keep providing continual feedback. There could be many people, who have genuine interest in the Product, but not everyone should be taken in to account as Stakeholders – some are purely engrossed bystanders. Clear identification of the stakeholders who have requirements is as important as determining the exact market segment you need to target for your products.
So, now we get another important question. Who or what qualities make a good stakeholder in Scrum?
Good stakeholders are those who provide constant and constructive feedback to the Scrum team and help in improving the product. One big challenge is to manage other stakeholders who don’t support or just become part of the scene. Good teams need strong leadership that can facilitate positive discussion and create better services or products.
Hence to be successful in a Scrum project understanding the needs and requirements of the stakeholders plays a very critical part and most of the times make or break the project.
Scrum Team, also referred to as the development team, is responsible for developing the product and they possess all the essential skills required to carry out the work of the project. They have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done. To minimize dependency, team members are experts in chosen domain, but also possess basic knowledge and skills about other domains.
Some of the challenges faced by a Scrum Team are:
Establish a common understanding of the customer’s requirements and the approach to develop the product
The Scrum Team consists of members with different levels of expertise, experiences, and viewpoints. So, all members should be aligned with the customer’s requirements to successfully develop the product and meet (or exceed) their expectations.
Function as a single unit to achieve the goals of the project
A Scrum Team is a cross functional unit that consists of members from diverse groups.This diversity might lead to friction within the team, especially in the formative stage. So, the team must strive to function as a single unit to avoid any internal conflicts that can disrupt work.
Create an environment that fosters collaboration among the Scrum Team members
Collaboration refers to a team proactively sharing thoughts, ideas and expertise to overcome challenges, or to improve a product’s quality. Collaborating can help a team deliver high quality products in a lesser time. Knowledge sharing is an important part of collaboration.
Be prepared to address customer’s change requests at any point during the product development lifecycle
Scrum projects are characterized by high rates of changes, depending on the customer’s requirements. Change requests may be initiated due to fluctuating market conditions, change in the preferences of end users, financial parameters, etc. So, the Scrum Team members should be able to accommodate change requests as the objective of a Scrum project is deliver functionality of the highest value to the customer.
Possess some business skills to ensure smooth communication with Product Owners and customers
Scrum Teams are often required to interact with Product Owners and sponsors. They might be required to negotiate with the Product Owner to decide which features can be delivered during a sprint or which features might contribute to the highest value. While the Scrum Team does possess technical skills, it is important that the team also possess adequate business knowledge to be able to better interact with the Product Owner.
Ensure team velocity is sustainable and that the team delivers the committed work
The Scrum Team should work at a pace that is sustainable. This means that the team should neither over estimate nor under estimate tasks. Estimating may be difficult initially. However, after a few sprints, teams should be able to estimate with more accuracy.
Since a sprint is time-boxed, the team must find an optimal rhythm to ensure that it meets the objectives of a sprint a time bound manner.
Ensure continuous process improvement
The Scrum team is responsible for continual process improvement over the course of a project. Teams must proactively participate in Daily Standup Meetings, Retrospect Sprint Meetings, and Retrospect Project Meeting to share their learning and brainstorm for process improvement.
Scrum believes that employees are self-motivated and seek to accept greater responsibility. So, they deliver much greater value when self-organized. The preferred leadership style in Scrum is “servant leadership”, which emphasizes achieving results by focusing on the needs of the Scrum Team.
Benefits of Self-Organization
Self-organization as an essential principle in Scrum leads to the following:
Team buy-in and shared ownership
Motivation, which leads to an enhanced performance level of the team
Innovative and creative environment conducive to growth
Self-organization does not mean that team members are allowed to act in any manner that they want to. It just means that once the Product Vision is defined in Create Project Vision process, the Product Owner, Scrum Master, and the Scrum Team get identified. And the Scrum Core Team itself works very closely with relevant Stakeholder(s) for refining requirements better as they go through the Develop Epic(s) and Create User Stories process. Team expertise is used to assess the inputs needed to execute the planned work of the project. This judgment and expertise are applied to all technical and management aspects of the project during the Create Deliverables process.
Although prioritization is primarily done by the Product Owner who represents the Voice of Customer, the self-organized Scrum Team is involved in task breakdown and estimation during the Create Tasks and Estimate Tasks processes. During these processes, each team member is responsible for determining what work he/she will be doing. Suring the execution of a Sprint, if team members need any help with completing their tasks, Scrum addresses this through the regular interaction mandatory with the Daily Standup Meetings. The Scrum Team itself interacts with other teams through the Scrum of Scrums Meetings and can look for additional guidance as required from the Scrum Guidance Body.
Finally, the Scrum Team and Scrum Master work closely to demonstrate the product increment created during the Sprint in the Demonstrate and Validate Sprint process where properly completed deliverables are accepted. Since the Deliverables are potentially shippable, (and the Prioritized Product Backlog is prioritized by User Stories in the order of value created by them), the Product Owner and the customer can clearly visualize and articulate the value being created after every Sprint; and Scrum Teams in turn have the satisfaction of seeing their hard work being accepted by the customer and other stakeholders.