Tag Archives: scrum master

How is Quality related to Scope and Business Value?

In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.

The fact that Scrum, through repetitive testing, requires work to be Done in an incremental fashion through Sprints rather than waiting until the end to produce deliverables results in errors being fixed right away, rather than postponed. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint. Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Quality and Scope

Scope and quality requirements for a project are determined by taking into consideration various factors such as the following:

  • The business need the project will fulfill
  • The capability and willingness of the organization to meet the identified business need
  • The current and future needs of the target audience

Scope of the project is the sum total of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

The Prioritized Product Backlog is continuously groomed by the Product Owner. The Product Owner ensures that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint. In general, the most valuable requirements in solving the customers’ problems or meeting their needs are prioritized as high and the remaining are given a lower priority. Less important User Stories are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. During Sprint execution, the Product Owner, customer, and the Scrum Team can discuss the list of features of the product to comply with the changing needs of the customers.

Quality and Business Value

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provide the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

The Scrum Guidance Body may define minimum quality requirements and standards required for all projects in the organization. The standards must be adhered to by all Scrum Teams in the company.

To know more please visit www.scrumstudy.com

Advertisements

Scrum: Change in Portfolios and Programs

Any change that arises in either the programs or portfolios may have a cascading effect on all dependent projects and Sprints. Therefore, it is advisable to minimize changes at these higher levels. If a change is required and all stakeholders are in agreement to make the change at these levels, the following should be kept in mind.

In Portfolio

  1. It is not recommended to make changes in between two Portfolio Backlog Meetings.
  2. If the change is minor, the Portfolio Product Owner should secure approval from the relevant stakeholders (e.g., sponsor, customer, and end user) and then add the requirements to the Portfolio Backlog. Product Owners of the program and project will consider those requirements for inclusion in future Sprints.
  3. If the change is major, the portfolio efforts along with associated programs, projects, and Sprints need to stop, and a Portfolio Backlog Meeting should be conducted to determine next steps.
  4. Portfolio Prioritized Product Backlog Meetings (also referred to as Portfolio Backlog Meetings), should be conducted at 4 – 12-month intervals. The frequency and impact of changes to a portfolio largely determine the time duration between two Portfolio Backlog Meetings. If there are several expected changes in portfolio, it is preferable to conduct Portfolio Backlog Meetings at more regular intervals (e.g., 4 – 6 months); but if there are fewer expected changes and if requirements are stable, the duration between two Portfolio Backlog Meetings could be increased (e.g., 9 to 12 months).

 

In Program

  1. It is not recommended to make changes in between two Program Backlog Meetings.
  2. If the change is minor, the Program Product Owner should secure approval from the relevant stakeholders (e.g., sponsor, customer, and end user) and the Portfolio Product Owner and then add the requirements to the Program Backlog. Product Owners for the project will consider those requirements for inclusion in future Sprints.
  3. If the change is major, the program efforts along with associated projects and Sprints need to stop, and a Prioritized Product Backlog Meeting should be conducted to determine next steps.
  4. Program Prioritized Product Backlog Meetings (also referred to as Program Backlog Meetings), should preferably be conducted at 2- to 6-month intervals. The frequency and impact of changes to a program largely determine the time duration between two Program Backlog Meetings. If there are several expected changes in program, it is preferable to conduct Program Backlog Meetings at more regular intervals (e.g., 2 to 3 months); but if there are fewer expected changes and if requirements are stable, the duration between two Program Backlog Meetings could be increased (e.g., 5 to 6 months).

The following figure demonstrates how changes can be managed within the Scrum flow for both portfolios and programs.

What is Scrum of Scrums?

What is Scrum of Scrums and how does it work in the product development process? The first thing to know about Scrum of Scrums is that it acquires relevance only for large projects where multiple Scrum Teams are involved. In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams.Normally, one member from each Scrum Team will represent his or her team in the Scrum of Scrums Meeting. In most cases, this is the Scrum Master, but at times someone else may represent the team. A single person may be nominated by the team to represent them in every Scrum of Scrums Meeting, or the representative may change over time, based on who can best fulfill the role depending on current issues and circumstances. Each person involved in the meeting should have the technical understanding to be able to identify instances in which teams could cause each other impediments or delays. Other important participants of Scrum of Scrums meeting include Chief Scrum Master and Chief Product Owner. The main purpose of the Scrum of Scrums Meeting is to communicate progress between multiple teams. The Chief Scrum Master (or any Scrum Master who would facilitate the Scrum of Scrums Meeting), can announce an agenda prior to the meeting. This allows individual teams to consider the agenda items in preparation for the Scrum of Scrums Meeting. Any impediments being faced by a team, which may also affect other teams, should be indicated so they can be conveyed at the Scrum of Scrums Meeting. In addition, if a team becomes aware of a large scale issue, change or risk that may affect other teams that should be communicated at the Scrum of Scrums Meeting. Outputs from the process Retrospect Sprint may have issues that could impact multiple Scrum Teams and could be used as an input for effective Scrum of Scrums Meeting. These meetings are preferably short (but usually not Time-boxed to allow for more sharing of information between teams) where a representative from each Scrum team meets to share status of the respective teams. The Scrum of Scrums Meeting is held at pre-determined intervals or when required by Scrum Teams, and these meetings facilitate the face-to-face sharing of information among different Scrum Teams through the Scrum of Scrums, issues, dependencies, and risks impacting multiple Scrum Teams can be closely monitored, which helps the various teams working on a large project better coordinate and integrate their work. It is the responsibility of the Chief Scrum Master (or another Scrum Master who facilitates the Scrum of Scrum Meetings) to ensure that all representatives have an environment conducive to openly and honestly sharing information, including feedback to other team representatives. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. Each Scrum Team representative will provide updates from his/her team in turn. These updates are usually provided in the form of answers to four specific questions.

  1. What has my team been working on since the last meeting?
  2. What will my team do until the next meeting?
  3. What were other teams counting on our team to finish that remains undone?
  4. What is our team planning on doing that might affect other teams?

The answers to these four questions provide information that allows each team to clearly understand the work status of all other teams. It is recommended that a dedicated conference room be made available for the Scrum of Scrums Meeting, where all the Scrum Team Representatives are comfortable. In Convene Scrum of Scrums process, Scrum Guidance Body Expertise could relate to documented best practices about how to conduct Scrum of Scrum Meetings, and incorporate suggestions from such meetings in project work of individual Scrum Teams. There may also be a team of subject matter experts who may help the Chief Scrum Master facilitate the Scrum of Scrum Meeting. Some of the important outputs of the Scrum of Scrums meetings are: Coordination of work across multiple Scrum Teams. This is especially important when there are tasks involving inter-team dependencies. Incompatibilities and discrepancies between the work and deliverables of different teams are quickly exposed. This forum also gives teams the opportunity to showcase their achievements and give feedback to other teams. By using Scrum of Scrums Meeting, there is collaboration across the organization as opposed to people working in closed teams concerned primarily with their individual responsibilities. The Scrum of Scrums Meeting is a forum where Scrum Team members have the opportunity to transparently discuss issues, impacting their project. The need to deliver every Sprint on time forces the teams to actively confront such issues early instead of postponing seeking resolution. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improve coordination between different Scrum Teams and also reduces the need for redesign and rework. Risks related to dependencies and delivery time tables are mitigated as well.

To know more please visit www.scrumstudy.com

What is Scrum of Scrums?

What is Scrum of Scrums and how does it work in the product development process? The first thing to know about Scrum of Scrums is that it acquires relevance only for large projects where multiple Scrum Teams are involved. In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams.Normally, one member from each Scrum Team will represent his or her team in the Scrum of Scrums Meeting. In most cases, this is the Scrum Master, but at times someone else may represent the team. A single person may be nominated by the team to represent them in every Scrum of Scrums Meeting, or the representative may change over time, based on who can best fulfill the role depending on current issues and circumstances. Each person involved in the meeting should have the technical understanding to be able to identify instances in which teams could cause each other impediments or delays. Other important participants of Scrum of Scrums meeting include Chief Scrum Master and Chief Product Owner. The main purpose of the Scrum of Scrums Meeting is to communicate progress between multiple teams. The Chief Scrum Master (or any Scrum Master who would facilitate the Scrum of Scrums Meeting), can announce an agenda prior to the meeting. This allows individual teams to consider the agenda items in preparation for the Scrum of Scrums Meeting. Any impediments being faced by a team, which may also affect other teams, should be indicated so they can be conveyed at the Scrum of Scrums Meeting. In addition, if a team becomes aware of a large scale issue, change or risk that may affect other teams that should be communicated at the Scrum of Scrums Meeting. Outputs from the process Retrospect Sprint may have issues that could impact multiple Scrum Teams and could be used as an input for effective Scrum of Scrums Meeting. These meetings are preferably short (but usually not Time-boxed to allow for more sharing of information between teams) where a representative from each Scrum team meets to share status of the respective teams. The Scrum of Scrums Meeting is held at pre-determined intervals or when required by Scrum Teams, and these meetings facilitate the face-to-face sharing of information among different Scrum Teams through the Scrum of Scrums, issues, dependencies, and risks impacting multiple Scrum Teams can be closely monitored, which helps the various teams working on a large project better coordinate and integrate their work. It is the responsibility of the Chief Scrum Master (or another Scrum Master who facilitates the Scrum of Scrum Meetings) to ensure that all representatives have an environment conducive to openly and honestly sharing information, including feedback to other team representatives. For larger projects, involving a significant number of teams, multiple levels of these meetings may be convened. Each Scrum Team representative will provide updates from his/her team in turn. These updates are usually provided in the form of answers to four specific questions.

  1. What has my team been working on since the last meeting?
  2. What will my team do until the next meeting?
  3. What were other teams counting on our team to finish that remains undone?
  4. What is our team planning on doing that might affect other teams?

The answers to these four questions provide information that allows each team to clearly understand the work status of all other teams. It is recommended that a dedicated conference room be made available for the Scrum of Scrums Meeting, where all the Scrum Team Representatives are comfortable. In Convene Scrum of Scrums process, Scrum Guidance Body Expertise could relate to documented best practices about how to conduct Scrum of Scrum Meetings, and incorporate suggestions from such meetings in project work of individual Scrum Teams. There may also be a team of subject matter experts who may help the Chief Scrum Master facilitate the Scrum of Scrum Meeting. Some of the important outputs of the Scrum of Scrums meetings are: Coordination of work across multiple Scrum Teams. This is especially important when there are tasks involving inter-team dependencies. Incompatibilities and discrepancies between the work and deliverables of different teams are quickly exposed. This forum also gives teams the opportunity to showcase their achievements and give feedback to other teams. By using Scrum of Scrums Meeting, there is collaboration across the organization as opposed to people working in closed teams concerned primarily with their individual responsibilities. The Scrum of Scrums Meeting is a forum where Scrum Team members have the opportunity to transparently discuss issues, impacting their project. The need to deliver every Sprint on time forces the teams to actively confront such issues early instead of postponing seeking resolution. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improve coordination between different Scrum Teams and also reduces the need for redesign and rework. Risks related to dependencies and delivery time tables are mitigated as well.

 To know more visit http://www.SCRUMstudy.com

Types of Scrum Masters

The Scrum Master is the “servant leader” of the Scrum Team who moderates and facilitates team interactions as team coach and motivator. The Scrum Master is responsible for ensuring that the team has a productive work environment by guarding the team against external influences, removing any obstacles, and enforcing Scrum principles, aspects, and processes. Different Scrum projects have different requirements, hence the need for different levels of Scrum Masters. Here are three such roles:

Chief Scrum Master

Large projects require multiple Scrum Teams to work in parallel. Information gathered from one team may need to be appropriately communicated to other teams—the Chief Scrum Master is responsible for this activity. The role of a Chief Scrum Master is necessary to ensure proper collaboration among the Scrum Teams. Coordination across various Scrum Teams working on a project is typically done through the Scrum of Scrums (SoS) Meeting. There is no hierarchy between the Scrum Masters: they are all peers. The Chief Scrum Master just works on a multi-team level, whereas the Scrum Masters work on a single team level. Typically, any inter-team issues are addressed by the interested parties in a session immediately following the Scrum of Scrums Meeting. The Chief Scrum Master facilitates this session. The Chief Scrum Master can be chosen from the Scrum Masters of the large project or can be somebody else. For very large projects, it is recommended to have a Chief Scrum Master who is not also a Scrum Master because the effort required for the Chief Scrum Master role will prevent the Chief Scrum Master from also being able to dedicate enough time to the work with his/her Scrum Team. In either case, the Chief Scrum Master should have enough Scrum expertise to be able to foster collaboration and to help and coach others with the implementation of Scrum for a smooth delivery of the project’s products. Apart from clearing impediments and ensuring a conducive project environment for the Scrum Teams, the Chief Scrum Master also collaborates with the Chief Product Owner, other Scrum Masters, and Product Owners in activities such as developing the list of components and resources needed in common for all teams throughout the project. He/she facilitates everything that goes beyond the realm of a single Scrum Team. The Chief Scrum Master also interfaces with the Program Scrum Master to ensure alignment of the large project with the goals and objectives of the program.

Program Scrum Master

The Program Scrum Master is a facilitator who ensures that all project teams in the program are provided with an environment conducive to completing their projects successfully. The Program Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the program; provides guidance to Scrum Masters of individual projects; clears impediments for the different project teams; coordinates with the Scrum Guidance Body to define objectives related to quality, government regulations, security, and other key organizational parameters; and, ensures that Scrum processes are being effectively followed throughout the program. The Program Scrum Master interfaces with the Portfolio Scrum Master to ensure alignment of the program with the goals and objectives of the portfolio. He or she is also involved with appointing Scrum Masters for individual projects and ensuring that the vision, objectives, outcomes, and releases of individual projects in the program align with that of the program. This role is similar to that of the Scrum Master except it meets the needs of the program or business unit rather than of a single Scrum Team.

Portfolio Scrum Master

This role is similar to that of the Scrum Master except it meets the needs of the portfolio or business unit rather than of a single Scrum Team.

To know more http://www.SCRUMstudy.com

Types of Scrum Masters

The Scrum Master is the “servant leader” of the Scrum Team who moderates and facilitates team interactions as team coach and motivator. The Scrum Master is responsible for ensuring that the team has a productive work environment by guarding the team against external influences, removing any obstacles, and enforcing Scrum principles, aspects, and processes. Different Scrum projects have different requirements, hence the need for different levels of Scrum Masters. Here are three such roles:

Chief Scrum Master

Large projects require multiple Scrum Teams to work in parallel. Information gathered from one team may need to be appropriately communicated to other teams—the Chief Scrum Master is responsible for this activity. The role of a Chief Scrum Master is necessary to ensure proper collaboration among the Scrum Teams. Coordination across various Scrum Teams working on a project is typically done through the Scrum of Scrums (SoS) Meeting. There is no hierarchy between the Scrum Masters: they are all peers. The Chief Scrum Master just works on a multi-team level, whereas the Scrum Masters work on a single team level. Typically, any inter-team issues are addressed by the interested parties in a session immediately following the Scrum of Scrums Meeting. The Chief Scrum Master facilitates this session. The Chief Scrum Master can be chosen from the Scrum Masters of the large project or can be somebody else. For very large projects, it is recommended to have a Chief Scrum Master who is not also a Scrum Master because the effort required for the Chief Scrum Master role will prevent the Chief Scrum Master from also being able to dedicate enough time to the work with his/her Scrum Team. In either case, the Chief Scrum Master should have enough Scrum expertise to be able to foster collaboration and to help and coach others with the implementation of Scrum for a smooth delivery of the project’s products. Apart from clearing impediments and ensuring a conducive project environment for the Scrum Teams, the Chief Scrum Master also collaborates with the Chief Product Owner, other Scrum Masters, and Product Owners in activities such as developing the list of components and resources needed in common for all teams throughout the project. He/she facilitates everything that goes beyond the realm of a single Scrum Team. The Chief Scrum Master also interfaces with the Program Scrum Master to ensure alignment of the large project with the goals and objectives of the program.

Program Scrum Master

The Program Scrum Master is a facilitator who ensures that all project teams in the program are provided with an environment conducive to completing their projects successfully. The Program Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the program; provides guidance to Scrum Masters of individual projects; clears impediments for the different project teams; coordinates with the Scrum Guidance Body to define objectives related to quality, government regulations, security, and other key organizational parameters; and, ensures that Scrum processes are being effectively followed throughout the program. The Program Scrum Master interfaces with the Portfolio Scrum Master to ensure alignment of the program with the goals and objectives of the portfolio. He or she is also involved with appointing Scrum Masters for individual projects and ensuring that the vision, objectives, outcomes, and releases of individual projects in the program align with that of the program. This role is similar to that of the Scrum Master except it meets the needs of the program or business unit rather than of a single Scrum Team.

Portfolio Scrum Master

This role is similar to that of the Scrum Master except it meets the needs of the portfolio or business unit rather than of a single Scrum Team.

To know more please visit www.scrumstudy.com

How is Quality related to Scope and Business Value?

In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.

The fact that Scrum, through repetitive testing, requires work to be Done in an incremental fashion through Sprints rather than waiting until the end to produce deliverables results in errors being fixed right away, rather than postponed. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint. Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Quality and Scope

Scope and quality requirements for a project are determined by taking into consideration various factors such as the following:

  • The business need the project will fulfill
  • The capability and willingness of the organization to meet the identified business need
  • The current and future needs of the target audience

Scope of the project is the sum total of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

The Prioritized Product Backlog is continuously groomed by the Product Owner. The Product Owner ensures that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint. In general, the most valuable requirements in solving the customers’ problems or meeting their needs are prioritized as high and the remaining are given a lower priority. Less important User Stories are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. During Sprint execution, the Product Owner, customer, and the Scrum Team can discuss the list of features of the product to comply with the changing needs of the customers.

Quality and Business Value

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provide the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

The Scrum Guidance Body may define minimum quality requirements and standards required for all projects in the organization. The standards must be adhered to by all Scrum Teams in the company.

To know more please visit www.scrumstudy.com