ST-Manual Testing - 2 - Scrum
Agile - Scrum
Scrum is a framework for managing and completing complex projects. It is often used in software development but can be applied to any field. The core elements of Scrum include the Scrum Team, the Product Backlog, Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.
Some of the key benefits of following Scrum include:
1. Increased productivity and efficiency: Scrum help teams work together more effectively by breaking down complex tasks into smaller, manageable chunks and providing a clear framework for communication and collaboration.
2. Improved quality of deliverables: Scrum's emphasis on regular inspection and adaptation helps teams identify and address issues early on, which can lead to higher quality deliverables.
3. Increased transparency and predictability: Scrum's use of regular sprints and sprint planning, review, and retrospectives helps teams to better understand their progress and predict when they will be able to deliver working software.
4. Enhanced customer satisfaction: Scrum's focus on delivering working software in short sprints allows teams to get feedback from customers more frequently, which can help ensure that the team is building the right thing.
5. Improved team dynamics and motivation: Scrum's emphasis on self-organization and cross-functional teams can help build stronger, more motivated teams that are better equipped to handle complex challenges.
Scrum emphasizes on an iterative and incremental approach, with a focus on delivering working software frequently, typically every 2-4 weeks, and it's a way to manage the complexity of building a product, with an adaptive planning, inspection, and adaptation throughout the project.
Different terminology that we come across in scrum -
Product Backlog: A prioritized list of features and requirements for the product, owned by the Product Owner and used to guide the Development Team's work.
Sprint: A time-boxed period of typically 2-4 weeks during which the Development Team delivers a potentially releasable product increment.
Sprint Backlog: The set of items from the Product Backlog that the Development Team commits to completing during the Sprint.
Scrum Master: A facilitator and coach who helps the Scrum Team follow Scrum practices.
Development Team: A cross-functional team responsible for delivering a potentially releasable product increment at the end of each Sprint.
Product Owner: The person responsible for representing the stakeholders and defining the features and requirements of the product.
Sprint Planning: A meeting at the start of each Sprint where the Scrum Team plans the work to be completed during the Sprint.
Daily Scrum: A short daily meeting where the Development Team discusses progress, obstacles, and plans for the day.
Sprint Review: A meeting at the end of each Sprint where the Scrum Team demonstrates the work completed during the Sprint and gathers feedback from stakeholders.
Sprint Retrospective: A meeting after the Sprint Review where the Scrum Team reflects on the Sprint and identifies ways to improve for the next Sprint.
Increment: A deliverable that is an extension of all previous Product increments, it is expected to be in useable condition and demonstrate the value that the stakeholders expect, it is a sum of all the product backlog items completed during a sprint.
Time-box: A fixed period of time for an event or activity, such as a Sprint, Sprint Planning, Daily Scrum, Sprint Review, or Sprint Retrospective.
1. What are the ceremonies in scrum ?
In Scrum, there are several ceremonies (also known as events) that are held to help the team plan, organize, and review their work. These ceremonies include:
Sprint Planning: This ceremony is held at the beginning of each sprint to plan and organize the work that will be done during the sprint. The team discusses the goals of the sprint, reviews the backlog, and selects the items that will be worked on during the sprint.
Daily Scrum: This ceremony is held daily and is an opportunity for the team to quickly check in with each other and discuss progress and any issues that have arisen.
Sprint Review: This ceremony is held at the end of each sprint to review the work that was completed during the sprint and to demonstrate it to stakeholders.
Sprint Retrospective: This ceremony is held at the end of each sprint to reflect on the sprint that just ended, looking at what went well, what didn't, and how to improve in the next sprint.
Backlog grooming (or Product backlog refinement): This is an ongoing process where the team continuously maintain and prioritize the backlog items.
These ceremonies help to keep the team on track, ensure that everyone is aware of what is happening, and provide opportunities to make improvements and adjust the plan as needed.
2. Estimation process in scrum using poker.
In Scrum, estimation is the process of determining the relative size or complexity of items in the Product Backlog, such as user stories or tasks. One popular technique for estimation in Scrum is Planning Poker, also known as Scrum Poker.
Planning Poker is a consensus-based technique that involves the entire Development Team. Each team member is given a deck of cards with values such as "0," "1/2," "1," "2," "3," "5," "8," "13," "20," "40," and "100." These values represent the relative size or complexity of the item being estimated.
During the estimation process, the Product Owner presents an item from the Product Backlog and the team members simultaneously choose the card that represents their estimate. The team members then reveal their cards and discuss their estimates. If there is consensus, the item is given the chosen estimate. If there is no consensus, the team discusses and resolves any discrepancies before re-estimating.
The goal of Planning Poker is to arrive at a consensus estimate that is as accurate as possible. It is also a way to ensure that all team members have a shared understanding of the item being estimated and are committed to completing it.
It's important to note that Planning Poker is not a way to estimate absolute time or effort, but rather a way to compare the relative size and complexity of items in the Product Backlog, it's a way to make sure that the team is on the same page and the development will progress smoothly.
3. What is a story point ?
A story point is a unit of measure used in agile software development, specifically Scrum, to estimate the relative size or complexity of a user story or product backlog item. Story points are used to determine the amount of work required to complete a user story, and to plan and track progress in sprints.
The use of story points is an attempt to move away from traditional metrics like time or effort, which can be difficult to predict or compare across different teams or projects. Instead, story points are relative measurements that are assigned based on the team's understanding and experience of the work required to complete a user story.
In most cases, a story point estimation is done using a technique called Planning Poker, where the team members use a deck of cards with numbers, such as "0," "1/2," "1," "2," "3," "5," "8," "13," "20," "40," and "100," to represent their estimate of the size or complexity of a story.
Once the story point is determined, team can use this information for sprint planning, prioritizing the backlog and measuring progress. Story points are also used to track velocity, which is the average number of story points completed in a sprint. This information can be used to predict how many story points can be completed in future sprints and to identify trends in the team's performance over time.
4. How can we give story points during sprint planning ?
Estimating story points during sprint planning is a key part
of agile software development. Here's a general process to follow:
1. Define
the user story: Start by defining the user story in clear, concise terms,
including the specific tasks and objectives that need to be accomplished.
2. Break
down the story into tasks: Identify the individual tasks that need to be
completed to fulfil the user story.
3. Assign
relative sizes: Assign a relative size to each task, based on its complexity
and level of effort. You can use a common scale, such as the Fibonacci sequence
(1, 2, 3, 5, 8, 13, etc.), to help make comparisons.
4. Establish
a consensus: Hold a discussion with the team members to reach a consensus on
the relative size of each task. Encourage everyone to provide their
perspectives and ask questions.
5. Add
up the relative sizes: Add up the relative sizes of all the tasks to determine
the total story points for the user story.
6. Repeat
for all stories: Repeat the process for all the stories in the sprint.
7. Review
and adjust: Regularly review the estimates and adjust them as needed based on
new information or changing requirements.
It's important to keep in mind that story point estimation
is an iterative process and the team's understanding of the stories will evolve
as they work through them. The goal is to reach a common understanding of the
level of effort required for each story and to prioritize the stories based on
their relative importance.
5. Can we map time to story point?
Story points are a relative measure of the size or complexity of a user story or product backlog item and are not directly related to time. In Scrum, the team's focus is on delivering a potentially releasable product increment at the end of each sprint, not on working a certain number of hours or days. However, it's possible to map time to story points over time, by looking at the team's velocity, which is the average number of story points completed in a sprint. Velocity can be used to predict how many story points can be completed in future sprints, and to plan and track progress in sprints. To map time to story points, the team needs to track their velocity over time, this is done by calculating the average of the story points delivered in each sprint, once the team has a history of sprints and corresponding story points, they can use this information to estimate the time it will take to deliver a certain number of story points. It's important to note that this is only an estimate and will vary depending on the complexity of the user stories, the team's skill level and other external factors, it's not an exact science and it should be used as a rough estimate. Additionally, the team should be aware that this mapping is not a one-time event, and it will change over time as the team's performance changes.
6. What is velocity in scrum ?
In Scrum, velocity is a measure of the amount of work that a team can complete in a sprint. It is typically measured in terms of story points, which are a relative unit of measure used to estimate the size or complexity of a user story or product backlog item. Velocity is used to predict how much work can be completed in future sprints, and to plan and track progress in sprints. Velocity is calculated by summing the story points of all the user stories that were completed during a sprint. It is important to note that story points are not directly related to time, but rather to the relative size or complexity of the user stories. The team can use their velocity to plan the next sprint, by selecting several user stories from the product backlog that they believe they can complete within the time-box of the sprint, based on their velocity. Additionally, the team can use their velocity to track their performance over time, by comparing the velocity of one sprint to the next, if the team's velocity is consistently increasing, it's an indication that the team is becoming more efficient, if it's decreasing, it's an indication that the team is facing challenges. It's important to note that velocity is not a measure of the team's productivity, it's a measure of the team's performance and it's affected by many factors such as the complexity of the stories, the skill level of the team members, and other external factors.
7. How do we calculate the velocity for the first sprint ?
Calculating velocity for the first sprint can be challenging, as the team may not have a history of completed sprints to use as a reference. However, there are a few ways to estimate the team's velocity for the first sprint:
Historical data: If the team has worked on similar projects in the past, they can use the data from those projects to estimate their velocity for the first sprint.
Expert estimation: Team members with experience in similar projects can use their knowledge and experience to estimate the team's velocity for the first sprint.
Smaller Sprints: Start with smaller sprints, for example one-week sprints, this will help the team to get familiar with the process, and to have a better understanding of their performance and their velocity.
Planning Poker: Use Planning Poker to estimate the size of the user stories, this will give you a rough idea of the complexity of the stories and thus, the team's velocity.
Iterative Approach: Start with a small set of stories, and after each sprint, reassess the team's performance, and adjust the number of stories for the next sprint accordingly.
It's important to note that the first sprint velocity should be considered as a rough estimate, and it will likely change as the team becomes more familiar with the process, and the complexity of the stories. Additionally, it's important that the team should not focus on the exact number but rather the relative size of the stories and their performance.
8. How can we baseline story point for the first sprint ?
Baselining story points for the first sprint can be challenging, as the team may not have a history of completed sprints to use as a reference. Here are a few ways to baseline story points for the first sprint:
Expert estimation: Team members with experience in similar projects can use their knowledge and experience to estimate the size of the user stories and baseline the story points.
Planning Poker: Use Planning Poker to estimate the size of the user stories. Planning Poker is a consensus-based technique that involves the entire Development Team and it's a way to make sure that the team is on the same page regarding the size of the stories.
Smaller Sprints: Start with smaller sprints, for example one-week sprints. This will help the team to get familiar with the process and to have a better understanding of the size of the stories.
Iterative Approach: Start with a small set of stories, and after each sprint, reassess the story point estimation and adjust them accordingly.
Baseline with similar projects: If the team has worked on similar projects in the past, they can use the data from those projects to baseline the story point for the first sprint.
It's important to note that the first sprint story point baseline should be considered as a rough estimate, and it will likely change as the team becomes more familiar with the process, and the complexity of the stories. Additionally, it's important that the team should not focus on the exact number but rather the relative size of the stories and their performance.
9. Difference between spill over and rollover in Scrum ?
In Scrum, spillover and rollover refer to the items that are not completed during a sprint and need to be carried over to the next sprint. Spillover refers to the items that were not completed during a sprint because the team underestimated their size or complexity. These items are carried over to the next sprint and added to the sprint backlog. The team will then need to re-estimate the size or complexity of these items and plan for their completion in the next sprint. Rollover, on the other hand, refers to items that were intentionally not completed during a sprint. These items are also carried over to the next sprint and added to the sprint backlog. The team may choose to rollover items if they believe they will not be able to complete them in the current sprint, but they are still important to the overall project. In both cases, the team should reassess the items and adjust their plan for the next sprint accordingly. The key difference between the two is that spillover is due to an underestimation of the effort required, while rollover is a conscious decision to prioritize other items over it. It's important to note that both spillover and rollover can have a negative impact on the team's performance, and the team should strive to minimize them, by improving their estimation process, and by focusing on delivering the most important items first.
10. Difference between a user story and a requirement ?
In software development, a user story is a brief, informal description of a feature or functionality from the perspective of an end-user. It is typically written in natural language and follows the format "As a [user], I want [feature], so that [goal]." User stories are used in agile development methodologies, such as Scrum, to capture the requirements of a project in a way that is easily understood by the entire development team. A requirement, on the other hand, is a detailed specification of what a system or product should do. Requirements can be functional or non-functional, and they can be expressed in various forms, such as natural language, use cases, or formal specifications. A key difference between user stories and requirements is that user stories are focused on the user's perspective and what they want the system to do, while requirements are focused on what the system needs to do to meet the user's needs. User stories are more high-level and informal, while requirements are more detailed and formal. User stories are used to capture the requirements of a project in a way that is easily understood by the entire development team, and they are used to guide the development process. Requirements, on the other hand, are used to specify what the system needs to do, and they are used to ensure that the system meets the needs of the user and other stakeholders. In summary, user stories are used to capture the high-level requirements of a project, while requirements are used to specify the detailed functionality of the system. User stories are often used as a starting point to create more formal requirements, but they can also be used alone to capture the overall requirements of the project.
11. Difference between Sprint backlog and Product backlog?
In Scrum, the Sprint Backlog and the Product Backlog are two different lists used to manage the work that needs to be done on a project. The Product Backlog is a prioritized list of all the features, functions, and requirements that are needed to complete a project. It is owned by the Product Owner, who is responsible for defining the features and requirements of the product. The Product Backlog is used to guide the Development Team's work and to ensure that the most important items are worked on first. The Sprint Backlog, on the other hand, is a subset of the Product Backlog that the Development Team commits to completing during a sprint. It is a list of items that the team has selected from the Product Backlog to work on during the current sprint. The Sprint Backlog is used to plan and track the work that needs to be done during a sprint. In other words, the Product Backlog is a list of all the things that need to be done, while the Sprint Backlog is a list of the things that will be done during the current sprint. The Product backlog is a long-term view of the project, while the Sprint backlog is a short-term view of the project, the team selects the most important items from the Product backlog to work on during the current sprint. It's important to note that the Sprint Backlog is an evolving list, and it will change as the team completes items and adds new items to the list during the sprint, and the Product backlog can also change as the team obtains more knowledge of the project and its requirements.
12. How do a scrum master track and monitor status in Scrum?
A Scrum Master is responsible for facilitating the Scrum process and helping the team to follow Scrum practices. As such, they play a key role in tracking and monitoring the status of a project. A Scrum Master can track and monitor the status of a project by utilizing various Scrum tools such as the Sprint Backlog, Sprint Burn-down Chart, and Sprint Retrospective. The Sprint Backlog is a list of tasks that need to be completed during the current sprint, and the Scrum Master can use this to track the progress of the team. The Sprint Burn-down Chart shows the amount of work remaining in the sprint, and the Scrum Master can use this to monitor the team's progress. The Sprint Retrospective is a meeting where the team reflects on their performance during the sprint and identifies areas for improvement, and the Scrum Master can use this to track the team's progress over time. Additionally, the Scrum Master can also use regular stand-up meetings, or daily scrums, to check in with the team, and ensure that everyone is aware of their tasks and responsibilities.
Here are a few ways a Scrum Master can track and monitor status in Scrum:
Daily Scrums: The Scrum Master facilitates the Daily Scrum, a short daily meeting where the Development Team discusses progress, obstacles, and plans for the day. This is a great way for the Scrum Master to get a sense of the team's progress and to identify any potential issues that need to be addressed.
Sprint Backlog: The Scrum Master should monitor the Sprint Backlog, which is the set of items from the Product Backlog that the Development Team commits to completing during the Sprint. They should track the progress of each item and ensure that the team is on track to complete the items within the sprint.
Sprint Goal: The Scrum Master should also monitor the progress towards the sprint goal and ensure that the team is working on the most important items.
Sprint burndown chart: The Scrum Master should monitor the sprint burndown chart, which is a visual representation of the work remaining in the sprint, to ensure that the team is on track to complete the work within the sprint.
13. What is the definition of done in scrum ?
In Scrum, the "Definition of Done" (DoD) is a shared understanding of what it means for a product backlog item to be considered complete and ready for release. It is a set of criteria that must be met before a product backlog item can be considered done. The Definition of Done is used to ensure that all the stakeholders have a clear understanding of what is expected from a product backlog item and that the team is working towards a common goal. The Definition of Done typically includes both functional and non-functional requirements, and it can include items such as:
· The item must meet acceptance criteria.
· The item must be thoroughly tested and pass all testing.
· The code must be reviewed and meet coding standards.
· The item must be integrated with other parts of the system.
· The item must be documented.
· The item must be ready for deployment or release.
It's important to note that the Definition of Done should be created and agreed upon by the entire Scrum team, including the product owner, development team, and Scrum Master. This ensures that everyone is on the same page and that the team is working towards a shared understanding of what it means for a product backlog item to be considered done.
14. What is Acceptance criteria in Scrum?
In Scrum, acceptance criteria are a set of specific, testable conditions that a product backlog item must meet to be considered "done." They are used to define and communicate the desired functionality and quality of a product backlog item to the development team, and they serve to ensure that everyone has a shared understanding of what the item should do. Acceptance criteria are typically created by the product owner, in collaboration with the development team and other stakeholders, during the product backlog grooming process. They should be clear, concise, and specific, and they should be written in a way that allows them to be easily tested and verified. Acceptance criteria can include both functional and non-functional requirements, such as:
· The item must perform a specific action or function.
· The item must meet certain performance or usability standards.
· The item must be compatible with other parts of the system.
· The item must be secure and comply with relevant regulations.
· The item must be accessible and usable by all intended users.
Acceptance criteria are used to guide the development team in the implementation of a product backlog item and to serve as a basis for testing and validation. They are also used to evaluate the item against the Definition of Done (DoD), to ensure that it meets all the necessary requirements before it can be considered complete and ready for release.
15. What is a User Story in Scrum?
A user story in Scrum is a short, simple description of a feature or functionality that a user needs or wants from the product being developed. It is written from the perspective of the end user and typically follows the format of "As a [user], I want [feature], so that [benefit]." User stories are used to capture the requirements for a product backlog item and to help the development team understand the user's needs and goals. User stories are a key element of Scrum, as they provide a simple way to communicate requirements to the development team and to prioritize them based on their value to the user. They are small and manageable, typically taking no more than a few days to complete, and they are easy to understand and implement. User stories are typically created by the product owner, in collaboration with other stakeholders, during the product backlog grooming process. They should be clear, concise, and specific, and they should be written in a way that allows them to be easily understood by the development team. During the sprint planning meeting, the team will select user stories from the product backlog to work on during the upcoming sprint. And as the team works on a user story, they will break it down into smaller tasks and add them to the sprint backlog. User stories are also used to evaluate the item against the Definition of Done (DoD), to ensure that it meets all the necessary requirements before it can be considered complete and ready for release.
Sample user story 1
Description :
As a user, I want to be able to search for a specific product on the website, so that I can quickly find what I'm looking for.
Acceptance Criteria:
· The search bar is prominently displayed on the homepage.
· Search results page displays relevant products based on my query.
· I can sort the search results by various criteria (e.g., price, relevance)
· The search function should be able to handle misspellings and return relevant results.
· Display a message if no results are found for a specific query.
· The search function should be case-insensitive.
· Search results should be paginated for better usability.
Sample user story 2
Description :
As a frequent online shopper, I want to be able to save my favorite products for easy access in the future, so that I don't have to search for them again.
Acceptance Criteria:
· A "Save" button is displayed on each product page.
· When I click the "Save" button, the product is added to my "Favourites" list
· I can view my "Favourites" list by clicking on a link in the top navigation bar.
· The " Favourites " list is displayed in a grid layout with images of the products.
· I can remove a product from my "favourites" list by clicking a "Remove" button on the product card.
· I can see the number of products currently in my " Favourites " list on the navigation bar.
· I will be able to filter my Favourites list by category.
· I can sort the products in my " Favourites " list by various criteria (e.g. price, date added)
· The " Favourites " list should be available even when I am not logged in, but will be lost when I clear my browser's cache or when I log out
Sample Test cases for the above user story:
1. Verify that the "Save" button is displayed on each product page.
2. Test that the product is added to the " favourites “ list when the “Save” button is clicked.
3. Verify that the “ favourites “ list can be accessed by clicking on the link in the top navigation bar.
4. Check that the “ favourites “ list is displayed in a grid layout with images of the products.
5. Test the functionality of the “Remove” button on the product card, ensuring that the product is removed from the “ favourites “ list.
6. Verify that the number of products in the “ favourites “ list is correctly displayed on the navigation bar.
7. Check those products in the “ favourites “ list can be filtered by category.
8. Verify that products in the “ favourites “ list can be sorted by various criteria (e.g., price, date added).
9. Test the “ favourites “ list availability without login and check that it is lost when the browser’s cache is cleared or when logged out.
10. Verify that the “favourites” list is persistent across browser sessions for logged in users.
Note: These are just sample test cases. The actual test cases will depend on the specific implementation and might require additional or different tests.
16. JIRA features for scrum?
JIRA is a software development tool that includes features specifically designed for scrum teams. Some of these features include:
Sprint planning: Allows teams to plan and organize their sprints, including creating and prioritizing tasks, and tracking progress throughout the sprint.
Sprint boards: Provides a visual representation of the tasks and their status within a sprint.
Burndown charts: Allows teams to track the progress of their sprints and identify any potential problems.
Backlog management: Enables teams to prioritize and manage their backlog of tasks.
Customizable workflows: Allows teams to create custom workflows that align with their scrum process.
Reports and Dashboards: Provides teams with detailed reports and dashboards to track progress and identify areas for improvement.
Overall, JIRA is a powerful tool for managing and tracking scrum projects, and its features can help teams to improve their workflow, collaboration, and overall productivity.
17. How to track status using Burndown Chart with picture
A burndown chart is a tool used to track the progress of a sprint in a Scrum project. It is a graphical representation of the amount of work remaining in a sprint over time. The chart is divided into two axes: the vertical axis represents the amount of work remaining, and the horizontal axis represents the time remaining in the sprint.
Here's an example of how a burndown chart may look like:
The ideal trend of the chart would be a downward slope, indicating that the team is completing tasks and reducing the amount of work remaining in the sprint. However, the reality is that the burndown chart may fluctuate and not be a straight line. A burndown chart can be used to identify problems and adjust the sprint as needed. For example, if the chart shows that the team is not completing enough tasks, the team may need to re-prioritize their tasks or add additional resources. In summary, a burndown chart is a tool that helps scrum teams to track the progress of a sprint and identify any potential problems. By monitoring the burndown chart, teams can make adjustments to the sprint as needed to ensure that the sprint is completed on time and within scope.
18. Difference between Burndown and Burnup charts in scrum?
Burndown charts and burnup charts are two different types of visual representations of work progress used in Scrum, a popular framework for Agile software development. A Burndown chart is a graphical representation of the amount of work remaining in a sprint, typically measured in story points. It shows how much work is remaining over time and helps the team understand how they are progressing towards completing their sprint goals. A Burnup chart, on the other hand, is a graphical representation of the amount of work completed in a sprint, typically measured in story points. It shows how much work has been completed over time and helps the team understand how they are progressing towards completing their overall product backlog. In summary, Burndown chart is used to track the progress within a sprint and burnup chart is used to track the progress of the entire product backlog.
19. Difference between and Epic and a User story in Scrum ?
In Scrum, an Epic is a large user story that represents a significant piece of work that needs to be broken down into smaller, more manageable stories. A User Story, on the other hand, is a small, self-contained piece of work that can be completed within a single sprint. An Epic typically represents a high-level goal or objective, while a User Story represents a specific feature or functionality that contributes to achieving that goal.
20. What is grooming in Scrum ?
In Scrum, grooming refers to the process of reviewing and refining the backlog of user stories. This process is typically led by the Product Owner and involves the development team. The goal of grooming is to ensure that the backlog is up to date, well-organized, and ready for the next sprint. During grooming, the team will review and clarify the requirements for each story, identify any dependencies or risks, and estimate the amount of effort required to complete the work. The team may also identify and split large stories into smaller, more manageable chunks. Grooming is an ongoing process that occurs throughout the project, typically before each sprint planning meeting. It helps the team to stay aligned on the priorities and goals of the project, and to ensure that the backlog is ready for the next sprint.
21. What is the role of a BA in grooming?
In Scrum, the role of a Business Analyst (BA) in grooming is to work closely with the Product Owner and the development team to ensure that the user stories in the backlog are well-defined and meet the needs of the stakeholders. During grooming, the BA may be responsible for facilitating discussions, gathering, and documenting requirements, and helping to clarify the acceptance criteria for each story. They may also help to identify any risks or dependencies that could impact the delivery of the story. Additionally, a BA could be responsible for creating wireframes, mock-ups, user flows, or other documentation that help to visualize and clarify the requirements for a story. They work closely with the product owner to make sure that the requirements are in line with the stakeholders' needs, and that they are understood by the development team. In summary, the BA's role in grooming is to ensure that the user stories are clearly understood by all stakeholders, and that they are ready for development in the next sprint.
22. Difference between velocity and capacity in scrum?
In Scrum, velocity is a measure of the amount of work that a team can accomplish in a sprint. It is typically measured in terms of story points, which are a unit of measure used to estimate the relative size and complexity of work items. Capacity, on the other hand, refers to the amount of time and resources that a team has available to work on sprint tasks. It is important to note that capacity is not a measure of how much work a team can complete, but rather how much time and resources they have available to work on completing tasks. In summary, velocity is a measure of how much work a team can accomplish in a sprint and capacity is a measure of how much time and resources a team has available to work on sprint tasks.
Comments
Post a Comment