Whether they admit it or not, all interviewees feel nervous when they appear for an interview! What helps to gain confidence is to gather as much knowledge as possible about Agile methodologies and principles and be well prepared before the interview. It’s important to make a good first impression, and for this you should be mindful of how you present yourself before the interviewer. This set of interview questions is carefully curated to equip you with relevant skills and will help you to get prepared and answer with good presence of mind and knowledge.
Agile adopts an iterative development methodology where the scope is defined through collaboration within the customer needs and Scrum teams.
The reason to adopt agile testing is to save money, time, and enable quick launch of the product in the market to beat the competition. Agile testing relies on continuous feedback from the end-user. Continuous feedback ensures building the right product, on time and within the customer’s expectations
Waterfall methodology follows linear sequential development. Agile follows an incremental approach of development and continuous feedback. Continuous Testing is one of several consecutive key actions that take place on most Agile projects.
Several activities that follow during Agile testing are as below:
Benefits of Agile Testing
The Agile Manifesto, considered by many to be the Bible of all things Agile, lays out the foundation for Agile. It is a document that outlines the central values and principles of Agile Software development. The four core Agile values help the team to improve their work processes. They help to improve upon the old traditional process which was not efficient and was so rigid that it could not easily handle changes.
The Agile Manifesto impacts Agile testers in many ways, which are outlined below:
In simple terms, the Test-Driven Development (TDD) method focuses on formulating unit test cases before forming the real code. It is an iterative approach and combines test cases and code.
The TDD approach derives its roots from Agile Manifesto principles and Extreme programming. It is a mode that permits developers and testers to obtain optimized code that is flexible in the long term.
Three phases of Test-Driven Development
Agile adopts an iterative development methodology where the scope is defined through collaboration between the customer’s needs and Scrum teams.
Organization ABC has just implemented the Agile methodology of testing. The product owner should consider some principles of the agile testing processes which are given below:
An IT organization has understood the importance of Agile testing. They are well aware of its benefits. Agile testing not only helps in delivering the product quickly and on time, but also offers many more benefits. Outline the benefits of Agile testing as compared to the traditional testing methodology.
Old traditional development methodologies, such as waterfall, follow linear sequential development/ testing processes. Agile testing offers more benefits than the old traditional testing methodologies. Testing using agile methodology ensures reduction in cost and the capability of delivering products of the highest quality that are in line with end-user expectations.
Below are the benefits of Agile testing:
Agile methodologies deploy continuous testing across iterations instead of only testing at the end, and result in products of superior quality.
Below are different approaches to Agile testing:
Agile is a set of practices that improve the efficiency of the software development process, teams, and organization. With the help of self-managing and cross-functional teams, high-quality solutions are delivered.
The Agile Project Life Cycle comprises the following:
A Pharma Organization is working on a very important project. They have picked a cross-functional team and are toiling day and night to complete the tasks. Unfortunately, the agile tester moves on and resigns. The project hence starts suffering and the organization is in search of a tester who can join with immediate effect. The Management promises to resolve this issue on a war footing. What is the importance of an Agile tester and what is their role in projects?
Agile testers play a very important role in maintaining the quality of the product developed. They are required to participate in project and development activities, and share their testing expertise and abilities.
Agile Testers ensure that the following is in place:
The Software testing process consists of various testing procedures and techniques. All these techniques are used to simplify the processes and improve efficiency. The implementation of agile testing procedures and techniques ensures high-quality delivery as the bugs are detected in the initial stage before the build is delivered to the end customer.
In the current era, agile testing has gained a lot of acceptance as it provides better results in a shorter time. The test plan is written and updated at every release.
Test plan in agile includes:
An eCommerce organization is working on a Payment Module. Currently, there are many eCommerce payment modules in the market. The stakeholders are innovating and conducting research on ways to beat the competition. They have planned rigorous changes and modifications for this module. What process or method of Agile testing should the organization implement to cope with these changes?
Extreme programming is a software development methodology that can be used here. Its values, principles, and practices, and goals allow small to mid-sized teams to deliver high-quality software. It helps the team to adjust, and evolve to changing requirements.
Extreme Programming includes
Agile testing refers to a software testing procedure in which software is checked for faults, mistakes, and other issues. It is regarded as an important aspect of the development process since it allows developers and testers to collaborate as a team, improving overall performance. It also contributes to the timely delivery of high-quality products. All the members of an agile team who have specific skills and knowledge are included in order to guarantee the timely delivery of a product with frequent releases of new features.
Agile testing is a process that relies on agile software development concepts. It is frequently done so that testers can spot and resolve issues early on in project development. In agile testing, development, and testing happen at the same time. The tester's responsibility is to act as a developer, providing improvements, recommendations, and test cases to be incorporated in the application rather than just detecting flaws.
Testers cover the entire product lifecycle with agile testing, but because of effective, continuous communication and regular interaction between customers and developers, the application may be provided quickly without affecting product quality. Instead of having a structured plan, the testers and developers react to sudden changes in the process and come up with quick solutions.
There are 7 main principles of Agile Testing. These include:
The following are some examples of Agile methodologies or frameworks that are extensively used around the world for software and project development:
The Scrum Master, the Product Owner, and the Developers are the three main roles in Scrum. The three roles undertake specific responsibilities and obligations to enable teams to deliver work effectively. As the basis of Scrum is self-organization, empiricism, and continual improvement, teams take ownership of how they structure themselves and continue to improve.
The Scrum Master is essentially the leader of the team or supervisor in charge of making sure that the Scrum team completes all of the tasks that have been assigned to them. The Scrum Master collaborates with the Scrum team to guarantee that each sprint is completed in a timely manner and that the team's workflow is in order.
The Product Owner is essentially a project stakeholder who is in charge of managing the product backlog. He or she is also in charge of defining the team's vision and goals. The Project Owner works with customers and end-users to gather requirements that the team can use to design the best product possible.
The Scrum Team is made up of individuals who are individually responsible for working together to achieve a certain project. It is the development team's responsibility to create genuine product increments and achieve sprint objectives. Every member of the team should be self-motivated, dedicated, and accountable for the work's high quality.
Agile Software Development is an iterative method for developing complex software. This strategy allows project teams to become more flexible while still ensuring that the end product meets the customer's needs. It creates customer-focused products and delivers them in shorter timeframes.
Traditional software development, on the other hand, is a method for creating simple software that follows a linear path. All parts of the process are normally carried out in this methodology in a sequential order. It is better suited to projects in which the scope of changes is limited.
Here are some of the differences between these two approaches:
Yes, the Agile methodology has some limitations, some of which are as follows:
The advantages of the Agile process include:
The disadvantages of using the Agile process include:
Re-factoring refers to a process that involves changing or modifying the internal structure of software without affecting its external functionality or behavior. Developers alter the code or experiment with it in order to enhance and improve the software's underlying structure. Red-Green refactoring is among the most popular and commonly used refactoring strategies in agile software development.
The refactoring process improves the readability, understandability, and cleanliness of the code. Refactoring on a regular basis makes it easier to expand and maintain code. The purpose of software development is to provide users and stakeholders with commercial value on a constant basis. It is challenging to retain and continually grow business value because technology is continuously changing, and corporate objectives are changing as well.
There are two possible future paths which include continuing to add new capabilities to a pre-existing code base, eventually resulting in an error-prone "throw-away" condition or modifying the system on a regular basis to ensure that it is capable of efficiently delivering not only present but also future business value.
Refactoring, the second option, is preferable. The usable life of an enterprise's software assets can be stretched out as long as necessary with continual refactoring. This means that customers can continue to get a value stream for years ahead. Refactors allow for an emergent design to guarantee that the system meets future business requirements.
The Product Backlog is an important list of items that includes everything that needs to be included in the final product. It consists of all of the Development Team's ideas, as well as the requirements of the Stakeholders, Product Owners, and others.
It serves as a source of prerequisites for product adjustments that must be made. Because all Sprint Backlogs are sourced from Product Backlogs, they can be regarded a subset of Product Backlogs. The Scrum process adds features and updates to the product in Sprints.
Here are the differences between these two backlogs:
The "Just in Time Production" philosophy is followed by the lean software development process. Its goal is to speed up software development while lowering costs. Lean is based on the principle of reducing non-value-added processes while increasing customer value. The agile process is a lean software development lifecycle method in and of itself.
Backlog grooming and code refactoring, on the other hand, suit agile approach better with lean concepts. Backlog grooming is the process of ensuring that the right items are in the backlog, that they are properly prioritized, and that those at the front of the backlog are ready to be delivered. In summary, the Lean methodology dictates that everything that does not provide value must be eliminated.
Removing waste entails not just the elimination of ineffective working methods like multitasking, but also the elimination of unnecessary tasks, meetings, and documentation. Here are some change concepts as a result of lean methodology:
Listed below are the good qualities that an Agile tester should possess.
Kanban is a well-known framework for Agile and DevOps software development. This is a tool that assists the team in keeping a careful tab on the task and determining its development. Kanban necessitates real-time capacity communication and complete work transparency. On a Kanban board, work items are visually depicted, enabling members of the team to see the status of each piece of work at any moment.
The Kanban board allows you to have the entire project scenario in one spot, giving you a clear image of the bottlenecks, completed tasks, and progress of the workflow. It enables the team to deliver a product on a consistent basis without being overburdened. Visualizing procedures and decision-making guidelines will aid in the proper execution of tasks and make it possible for different teams to discover and specify process changes. In addition, all project teams will be able to track their progress in real-time and select what to concentrate on first and what to undertake next.
Kanban methods first found acceptance in the manufacturing sector and have since been proven to drive success in Agile software development organizations. This methodology has just recently begun to be recognized by companies across diverse industries. Kanban strives to create a service-oriented mindset. It necessitates a deep understanding of your customer’s demands, the creation of a range of services where individuals self-organize around the task, and the continual evolution of your system.
Pair programming refers to a practice in agile software development where two programmers work together in one workspace to enhance efficiency. One programmer develops the code as the other observes reviews it. The two programmers regularly switch duties.
There are a number of benefits of taking this approach. These include:
There are some drawbacks of taking this approach which include:
Scrum of Scrums refers to a scalable agile technique for connecting several teams that need to collaborate to produce complex solutions. Whenever there are numerous teams working on a project, this term is used. It relates to the daily Scrum meeting's scalability. Every team is in charge of running and leading its own Scrum meeting in this case.
Nevertheless, in order to maintain communication and coordination amongst all the multiple teams, a separate meeting with all of the teams needs to be held. This is what the "Scrum of Scrums" is all about. It enables teams to design and deliver complicated products at scale by facilitating openness, inspection, and adaptation.
It is most successful when all effective Scrum team members work towards one goal, trust and respect each other, and are fully aligned. The bigger the number of lines of communication between members of the team, the more difficult it is to build trust and a single goal. As a result, dividing a big group into two or three smaller groups can aid in the development of interpersonal relations and the achievement of desired results.
Coordination is required when many teams are formed to achieve a common goal. This is what necessitated the creation of Scrum of Scrums. Scrum of Scrums teams not only coordinate delivery but also ensure that a completely integrated product is delivered at the end of each sprint. As a result, Scrum of Scrums serves as a release team responsible for delivering value to clients. This strategy is generally used as a first step in scaling Agile and organizing delivery of larger and more complicated products.
Agile refers to a development methodology that takes an iterative and incremental development approach. Scrum, on the other hand, is the most popular Agile framework in use by organizations worldwide. In Scrum, the customer receives incremental builds every 2 to 3 weeks.
Here are the differences between the two:
Agile testing quadrants represent a helpful taxonomy to help agile teams to identify, plan and execute the testing and ensure that all resources are available to accomplish it.
Refactoring improves the internal structure of the program source code without changing its internal behavior.
Refactoring would not mean
Benefits of refactoring:
The Product Backlog contains an essential list of items that are necessary for integrating into the product. Sprint backlogs are considered to be the subset of the product backlogs. As the sprint backlog is derived from the product backlog.
Following are the differences between the Product Backlog and Sprint Backlog
|Product Backlog||Sprint Backlog|
|It is the list of all the items that are required to complete the development of the product.||The sprint backlog is the subset of the product backlog. The items are extracted from the backlog to complete and are created as sprints. Sprints are the subset of product backlog.|
|The Product owner is responsible for the product backlog; He prioritizes and refines the items as required.||The Development team is responsible for the Sprint Backlog. They are responsible to complete all the items within the fixed timebox.|
|The entire goal of the product is captured in the Product Backlog.||The sprint backlog is limited to the Sprint goal in that particular Sprint.|
|Product Backlog can vary as per the changes in the business case or customer requirements.||The sprint goal will remain the same throughout the sprint.|
|The entire list needs to be completed to develop the product.||A subset of the product backlog needs to get completed during sprints.|
|Consists of product features and Stories.||Sprint backlog acts as a to do list. The development team breaks the user stories into separate and manageable tasks and these tasks should be completed within the specified timebox.|
|The product backlog has to be maintained till the entire project is closed.||Every new sprint gets a new backlog and needs to be completed within the stipulated time.|
Velocity predicts how much work can be completed by the development team within a two-week sprint. It is useful for estimating how fast and how long the team will take to complete a project.
The velocity is calculated by reviewing the work that the team has successfully completed during the previous 3 weeks. If the team completes 10 stories during the 2-week sprint and each story has 2 story points, then the team velocity is 30 points.
Example to calculate velocity in Agile:
Average sprint velocity = (12+35+28)/3 = 56
Sprint zero alias inception phase takes place before the start of the project. The goal of the inception phase or sprint zero is that the team comes together to develop minimal user stories, project skeleton, and to develop a workable product. The sprint must be lightweight.
Purposes of Sprint Zero
The purpose of this Sprint is to be productive. The Sprint should remain a lightweight exercise. By the completion of this Sprint prioritization of features or a list of Users, Stories should be completed.
Sprint zero purposes
Backlog refinement (Earlier known as backlog grooming) is an event during which the product owner and the team review items on the backlog to ensure that they are appropriate for the tasks at hand. They are prioritized, and the items are ready for delivery. This activity happens frequently or is an ongoing activity.
Activities that occur during the refinement are as below:
The goals of Backlog Refinement are as below:
A burndown chart represents how quickly the team is working on the customer user stories. The burndown chart depicts total effort against the amount of the work for each iteration
The burndown is a chart that explains how the team is burning customers’ user stories. It shows the total effort versus the amount of work we deliver for each iteration.
The above graph gives us:
Burndowns provide information as below:
Step 1: Create a table with the data to plot burndown chart
It is required to have three columns
Column A indicates time frame of sprint or task.
Column B would have number estimates of tasks/activities that are pending to be completed each day.
Column C would have estimates of actual work that is remaining to be completed each day.
The burndown charts can be created in Excel by using above data.
Burn-up charts are project management tools that visually represent the scope of a project or iteration (i.e., sprint). It represents the work that has been completed so far in the development process.
Two lines can be seen on the chart.
Burn-up and burndown charts are the two types of charts which track the progress of the projects. A burndown chart shows how much work is remaining and burn-up chart shows how much work is completed. These charts are collectively used in Agile projects.
The burndown chart shows the team did not accomplish much in the project but could finish all the tasks in the end. The burn-up chart indicates that the scope increased in the beginning and some scope was removed to meet the deadline of the project. The team then made steady progress throughout the project.
Agile Scrum methodology is used for the below reasons:
Acording to Atlassian, a sprint is a ‘short, time-boxed period when a scrum team works to complete a set amount of work’. The sprint term refers to accomplishing the goals within a predefined boxed time. The period of a sprint is usually short i.e., one or two weeks, and represents a timeboxed iteration of a continuous development cycle. The work in the sprint is planned and the team has to work to accomplish the goals and make it ready for review. Sprints are broken into small chunks of duration, and are no longer than 3-4 weeks.
|Exploratory Testing||Scripted Testing|
|Requires good knowledge of the domain. The testing is conducted by the individual tester who has good knowledge of the domain. ||Tester overcomes the lack of domain knowledge during the test design phase. The tester gains knowledge during the knowledge sharing sessions by subject matter experts. |
|It is more of a mindset ||Scripted testing is a formal testing methodology |
|It is suitable when requirements and specifications are not clear ||It is suitable when requirements and specifications are clear |
|Works well when the requirements change frequently ||Doesn’t work well when the requirements change frequently |
|Testers use logical reasoning to guide future testing. ||Testers follow step-by-step instructions and discourage deviations. |
|Testers feel more involved in exploratory testing ||Testers don’t feel involved as they have to follow step by step process |
|Bugs are detected quickly ||Bugs can be detected only at the end-of-life test cycle |
|Dependent on the skills of tester ||As the tester must follow the step-by-step process it is independent of the tester's skills |
|Effective when the testers are skilled ||Highly effective if the aspects and values that need to be tested are in sequence |
|Testers can change the test cased on the fly ||Testers have to follow a sequence test case in advance that are designed. |
|Testing is performed on the fly and hence test cases cannot be tested well in advance ||Test cases are prepared and reviewed well in advance. |
|There is no way to confirm that all requirements are met and implemented ||At the end of the testing life cycle the tester can confirm that all the requirements are met. |
|Repeating the same test becomes challenging as no documentation is created during exploratory test. ||The same tests can be repeated as the test scripts are defined in well advance. |
|Exploratory tests cannot be automated ||Scripted tests can be automated |
|Testers are not aware what to expect at the end of testing cycle ||Testers are aware what to expect at the end of testing cycle |
An Epic is a series of user stories that share a broader strategy. Several epics share a common goal and are grouped together under a business objective called as a theme. User story can be completed within the timeframe of a sprint, but an epic will typically require development work covering several sprints.
The Epic sits between Theme and Story in agile development. The theme represents a high-level strategy for its product. Themes are broken into several epics by the team and then epics are broken down into several user stories. A story represents a small unit of development work that will allow the user to complete the goals.
A User story is a brief explanation of a feature written from the user’s point of view. Agile experts describe a user story as the smallest unit of product development work.
User stories are the unit of development work designed to accomplish a specific goal within a product. A user story is written within the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].”
The Product team breaks the development work into user stories for several reasons:
Definition of Task:
User stories represent work broken down into single units, called tasks, that are usually completed by one person.
Use of Tasks:
Tasks are small increments of work to be completed during a sprint. The team creates tasks on post-it notes and puts them on up their Agile task board.
In the iterative process, progress is made through successive refinement of tasks. The development team creates/ develops the first cut and the team then iteratively improves parts until the full product is created satisfactorily. The customer’s feedback is taken after each iteration and then the software is enhanced in greater detail.
Let us take an example of search functionality on a website. For the first iteration, a simplistic search screen can be developed. In the next iteration, advanced search models would be added.
An incremental method entails producing components of the software in parts. Each increment outlines a complete subset of functionality and is entirely coded and tested.
For example, in an e-commerce store, initially, payment can be supported only via credit and debit cards. In the subsequent release, payment via wallets can be established and supported.
Sprint Zero is the iteration where the team get prepared for the project execution.
Sprint Zero is used for the following reasons.
A Spike is a task aimed at clarifying a question or collecting information, rather than at designing a shippable product. A spike is created to handle the task further after collecting relevant information and hence it can be estimated correctly.
Spikes are time-boxed activities that have precise goals and desired results. This technique enables delivery teams to determine how to deliver a working product efficiently.
Spikes can be of three types:
The principal roles are
An Impediment keeps the team away from getting work done and this slows down the velocity.
Impediments appear in various forms:
An accidental error by a software developer that seldom stops the build process, or causes unacceptable warnings in the automated test environments, is known as a "Build Breaker".
Continuous integration is an important characteristic of products developed through agile methodology. Developers sometimes make mistakes and accidentally commit flaws to the software repository. When such commits stop the build/compile process or cause unacceptable warnings or failures in the automated test environment, the build is said to be broken. The developer is assumed to have committed a build breaker.
User acceptance testing (UAT) is the last phase of development in which software users test the software to ensure that it can handle required tasks in real-world scenarios. It is also identified as beta testing, application testing, or end-user testing.
User Acceptance Testing (UAT) in Agile practices
A plan describing all aspects of the UAT is pulled up.
Test cases designing
Test cases are designed to cover all the functional scenarios of the software in real-world usage.
Selection of testing team
Testing team made up of real-world end-users is created.
Documenting test cases and execution
The team executes test cases, bugs and comments are logged.
The software development team fixes the listed bugs.
The testing team accepts the software application, which indicates that the application suffices user requirements and is equipped to be rolled out in the market.
A tracer bullet is a spike that is part of the production code. It would be executed within the current architecture and technology that is established along with the best practices that are within the current project development. It is of production quality code and the rest of the iterations are built on this code. This is the most important aspect as other developers will be using this same code to work on the next iterations or enhance new features.
In the E-commerce platform, a new service is developed. Let's name this service as ProductCountService. Now, this could be a tracer bullet as this service would be used by other developers to extend working on a similar sort of feature development task where they need to enhance the features. All the enhancements should adhere to code quality and best practices and the unit tests should be properly written and passed.
The build-breaker is a condition that occurs when there is a defect in the software. This results in a sudden unanticipated bug; the compilation process freezes or execution fails or a warning is caused. The duty of the tester is then to get the software back to the healthy working stage and it is the onus of the developer to resolve the bug and make this build normal, as soon as possible.
The daily stand-up is for sharing the daily status among all the members of an agile team. This forum helps to address and mitigate problems that the members face. It is a mandatory practice regardless of whether the teams are collocated or not.
What is Daily Stand-up?
Importance of Stand-up Meeting
Following are the benefits of having stand-up meetings
Stand-up meeting Audience
Sprint Review Meeting aka Sprint Demonstration is usually held on the last day of the sprint. It is held to demonstrate the product increment to stakeholders and the team. The Product Owner reviews the finished stories and marks them as Done or Not Done based on “Definition of Done”.
The audience of the Sprint Review Meeting
Scrum Team, the stakeholders, Business Sponsors and Management participate, and the objective of the meeting is to showcase the sprint increment to the audience of the sprint review meeting.
Stakeholders, Business Sponsors, Management Participates are not fixed participants.
The Product Owner Invites the stakeholders in advance. The Scrum Master facilitates the meeting, schedules it in advance, and sets the scope. The Key recipients can take a decision on how important it is for them to attend the meeting and may choose to opt out when not required.
The Development Team demonstrates the stories one by one as planned. The order can be changed on the Product Owner's request or on the key meeting recipient's request.
The Stakeholders evaluate the increments. They accept increment(s), recommend new changes for the future sprints, or can also repudiate the increment that is to be deployed.
The sprint retrospective is held at the end of a sprint to review what went well during the previous sprint and what can be improved for the next sprint.
Purpose of a sprint retrospective
The sprint retrospective is a timeboxed meeting that is held after the sprint review and before sprint planning for the next iteration.
The sprint retrospective meeting helps in the below ways:
To examine how the previous spring completed went and what can be done to improve the deliveries in the next sprint.
Scrum retrospective helps Scrum team members to classify how they can improve to contribute better to the sprint. The team would ask questions themselves like what work has been done well in this sprint? What work hasn’t been done well? What should we start doing to improve? The development team then focuses on improving quality by improving work processes or adapting the definition of “done.”
Sprint Retrospective Audience
It usually includes development team members, the Scrum Master, and the product owner. The Scrum Master conducts the meeting and assists the development team to enhance its workflow practices within the process framework for the next sprint.
Stakeholders and managers who are not directly part of the team usually don’t come to a Scrum retrospective unless they are invited. They engage in the sprint review meeting where the scrum team reveals what they have achieved and accomplished during the sprint through product demos.
Sprint planning is an event where the team handles the product backlog items, that they will work on through that sprint. The team chalks out their initial plan for completing those product backlog items. They establish sprint goals and, on that basis, they determine on which product backlog items they would work to complete their goals.
Sprint Planning Audience
Sprint planning involves the entire team.
A product owner proposes the product backlog items and their priorities to meet the sprint goals. The team determines how many items they would be able to complete and how they would deliver. The Scrum Master ensures that there is consensus on the sprint goal, and appropriate product backlog items are included in the sprint backlog.
Sprint Planning venue
Sprint planning is held in the team room so that it is easy to access all the information about your product backlog. If the team is distributed, sprint planning serves as a great opportunity to gather all distributed team members, so that the discussions would be more effective and strengthen connections among the team.
When does Sprint Planning take place?
Sprint planning occurs on the first day of a new sprint.
The event should occur after the sprint review and retrospective meeting so that any output from these meetings can be considered while planning for the new sprint.
Scrum ceremonies are vital ingredients of the agile and software delivery methodology process. These ceremonies implement the framework for teams to get work done in a structured way, aid to anchor expectations, authorize the team to cooperate effectively, and eventually prompt results. If these meetings are not managed appropriately, they can overwhelm calendars and kill the value they are expected to contribute. Often when teams quit certain ceremonies, it’s because they don’t see the advantage in them anymore.
These are the five key scrum ceremonies:
The metrics should be a combination of project-related metrics, as well as business metrics that help to view the progress of the team.
Here’s a list of the most important metrics:
1. Sprint Burndown
The burndown chart is a graphical illustration of the predicted Scrum tasks as compared to the actual tasks completed. The volume of work left is plotted versus time for the duration of the sprint. The output in the duration of hours, story point, or backlogs remaining can be calculated which enables tracking the real-time progress of the sprint.
2. Lead Time
Lead time is the duration of receipt of the requirement and its successful delivery. This includes the time duration from the actual commencement of the development process to the end of delivery.
Lead time and cycle time are popular Lean and Kanban metrics that help to identify potential bottlenecks within the process. It also provides stakeholders and clients necessary insights about the estimated velocity of development.
If the lead time is low, then the requirement moves faster from the backlog to the development phase, and this then lowers the cycle time and hastens the development process.
3. Flow Diagram
Cumulative flow is an essential Kanban metric for assuring a steady flow of work across the team. The cumulative flow diagram provides information for bottlenecks at any stage and is instantly envisioned and the work in progress is more easily tracked.
The intricacies can be tracked on a real-time basis during the process. The problem resolution and analysis take place instantly.
4. Sprint Velocity
Velocity is a measure of the amount of work the development team is able to perform in a given period of time. Velocity is an important metric; but it is relative and cannot be used as a measure of competence or performance of the agile team.
5. Failed Deployments
Failed or unsuccessful deployments are the deployments that fail to get pushed over a given period of time. These failed deployments can be calculated over a week, month or depending on the recurrence of your releases.
6. Code Coverage
Code coverage aka test coverage provides a much-needed view of the amount of untested code in your codebase. It is not a measure of how good your tests are but gives a rough visualization of the code that is incorporated by unit tests.
7. Net Promoter Score
NPS is a business metric that represents the likeliness of your customers to refer to their contacts. Customer analysis and collection of feedback are crucial in the calculation of the Net promoter score.
A Scrum of Scrums meeting is to manage large projects with varied teams. A Scrum of Scrums is held to assist interaction among teams that may have dependencies on one another. After the daily stand-up meeting, one member from all teams attends the Scrum of Scrums to represent his/her team to manage or handle questions or concerns of the team.
In case of teams working on a large project with dependencies, risks, or issues that could impact another team’s sprint goal, a Scrum of Scrums is scheduled to discuss or resolve these issues.
Following are the Benefits of Scrum of Scrums:
Automation testing is encouraged for testing on Agile projects because of the following reasons:
Agile estimations are relative estimations that allow teams to procure more information about the items. All estimations are done in relative units, usually in story points.
Agile estimation techniques are as below:
All members use numbered playing cards and estimate the tasks that need to be done to achieve the goals. Voting is done anonymously, and discussions are held when there are large differences. When the whole team reaches consensus, voting is stopped.
This is a perfect system for estimating a large backlog of large items. Items are estimated into t-shirt sizes: XS, S, M, L, XL. The determination about the size is based on open and mutual collaborative discussion.
A relatively simple and effective technique to estimate a small set of items using Dot Voting. This method originated from decision-making and can be used for estimating. Each person receives a small number of stickers and can decide how to vote for the items.
The Bucket System
A faster method than Planning Poker is the Bucket System. This system is a good option when it is used to estimate a large number of items, and the team has a large group of members. The group estimates the items by laying them in these “buckets”. A bucket is usually represented by a sheet of brown paper on which you can place sticky notes with the item names.
A fast method for rough estimating is the Large/Uncertain/Small method. The initial step is to classify the items into two extreme categories, and then place the mid-sized items between them. It is a simpler version of the bucket system. This system is better for use within smaller groups with comparable items.
This system is based on discovering associations in the estimated items. The team groups the items together in small groups to large groups. It works best with a small group of people and a relatively small number of items.
This is a practice to get an exact image of the relative size of items. All items are set in random order on a scale number varying from low to high. Every participant moves from one item on the scale. Each move is just one spot lower or one spot higher or to just pass on the turn. The ordering protocol is a process of arranging the items in fine-grained size estimates. It works best with a relatively small group of people and a large number of items.
The minimum viable product (MVP), as formerly defined by Eric Ries, allows testing an idea by exhibiting an initial version of the product to the target users and customers, collecting the appropriate data, and learning from it.
For instance, to examine the viability of using an Artificial intelligent Paywall product as the major revenue source, an early product version can be released to measure if and how often people use the product. We can view the MVP as a risk reduction tool as it will provide data of consumer behaviour using which it can be enhanced to have a full-proof product. MVP is about learning, and it’s no surprise that it plays a key part in Lean Start-up's build-measure-learn cycle.
The Minimal Marketable Product encourages creating a minimal offering of the product in the market. It includes the smallest possible feature set that meets the needs of the initial users. The MMP is a tool to lessen time-to-market launch. Designing a product with just the right amount of features sounds like common sense.
An example of an MMP is Apple’s original iPhone launched in 2007. The first iPhone was a complex product and the phone did provide just a few features. To determine the right features, the aforementioned MVP is a fantastic tool.
A Scrum Master works with the product owner and the Scrum team to refine and improve processes where it makes sense.
A Scrum Master has the following roles and responsibilities
Coach team members
The Scrum Master ensures that team members are well trained and have experience in Agile processes. The Scrum Master takes utmost care that the team members have a sense of project ownership and that teams are self-managed.
Host daily stand-up meetings
Daily Scrum, or stand-up, meetings last for 15 minutes. Each team member gets the opportunity to answer these questions:
Helps product owner with the product backlog
The product owner is accountable for creating and maintaining the product backlog. The product backlog is a list of items that the agile team would work on to achieve the goals defined. The Scrum Master helps the product owner to refine the product backlog with the information gathered from daily stand-up meetings.
The Scrum Master protects the team from distractions and roadblocks that can impede progress.
For example, if team members are dragged into many unimportant meetings, the Scrum Master intervenes and determines who really needs to attend the meetings.
Practices and principles
To assure that work is not slowed down, the Scrum Master acts as a mentor and teacher to placidly onboard new employees or team members. The Scrum Master also helps new team members to understand the scope of a product and ensures that newly joined team members understand and adhere to Scrum practices and rules.
To calculate velocity, we will use story points to measure the amount of work completed in each sprint.
Step 1: Calculate how many user story points are achieved in each sprint
In sprint 1:
A team committed to achieving/ completing 6 user stories.
Each user story had eight-story points, making a total commitment of 48 story points.
The team completed three of the six user stories.
In sprint 2:
The team this time committed to eight user stories (including three user stories from the sprint 1).
User stories had eight-story points, making a total commitment of 64 story points.
This time team completed five out of the eight user stories.
In sprint 3:
The team again committed to nine user stories.
Each user story had ten-story points, making a total commitment of 80 story points.
The team was able to complete seven of the ten user stories.
Step 2: Average calculation of completed story points
Add the total of story points completed, then divide by the number of sprints.
Total = 120
Average sprint velocity is 120 ÷ 3 = 40.
The amount of work that can be completed in future sprints on an average is 40 story points. If there are in total 192 story points remaining to be completed, it can be assumed that the team would require approximately 4 more sprints to complete the user stories in the project.
The product roadmap is a high-level summary that charts out the vision and direction of the product that we are developing over time. A product roadmap describes why and what is getting built and it is a plan for executing the product strategy.
The product roadmap is created to achieve goals as below:
Product RoadMap contents include
A Sprint can be cancelled before the Sprint time-box is accomplished. The Product Owner has the authority to cancel the Sprint, and the product owner may do so after consultations with the stakeholders, the Development Team, or the Scrum Master.
Following are the reasons that a Product owner Might Cancel a Sprint:
Story Maps were initially introduced by Jeff Patton in 2005. The principal idea behind Story Maps is that single-list product backlogs are very difficult to organize and prioritize A need for richer structure arose and hence the story map concept was introduced. A story mapping is a compelling device that facilitates an agile team to refine their product backlog and design the product releases more efficiently.
Few benefits of using a story map:
Scope creep—It is an inclination for software projects to extend beyond their original bounds. Avoiding scope creep improves the chance of delivering the project on time and within budget. Smaller projects have a greater chance of success; hence this is the reason that a large assignment is split into smaller components.
Below are the 8 tips to prevent scope creep from taking over your project
The Definition of Done generates clarity by granting everyone a shared perception of what work was completed or developed as a component of the Increment. If a Product Backlog item does not satisfy the Definition of Done, it cannot be published or even inferred at the Sprint Review meeting with stakeholders, customers, etc. Alternatively, it reverts back to the Product Backlog for future deliberation.
A servant leader is a servant first. The purpose of this concept is to improve and enhance teamwork, individual responsibility and accountability.
A servant leader is one who
He or she ensures that the team is getting together well, understands the team needs, understands the business objectives, and thereby works towards the common goal. The Scrum Master smoothens impediments, and irons out any conflicts that may arise within the team.
The concept of servant leadership is all about
In the Scrum agile framework, the Definition of Ready outlines the elements that must be answered in sequence for a story to move from the backlog to development. Ready is often interpreted as a story that can be portrayed instantly.
Typical items considered for a definition of ready:
Scrumban is an Agile development methodology that is a combination of Scrum and Kanban.
Scrumban was developed to meet the requirements of teams who wanted to reduce the batching of work and embrace a pull-based method. A mixture of Scrum and Kanban provides teams the versatility to accommodate stakeholder and production requirements without getting overburdened by their project methodology.
Scrumban renders the edifice of Scrum with the versatility and visualization of Kanban, delivering a highly adaptable path to workflow management. Scrumban can be used as a steppingstone for teams attempting to transition from Scrum to Kanban. An immediate shift to Kanban would be futile to developers and scrumban allows teams to learn a process of how to practice perpetual development and improvement in Kanban without dropping the common structure of Scrum.
Agile uses empiricism in order to adjust to the dynamic requirements of the customer. Empiricism is the act of addressing and making decisions based on what is really experienced. The empirical strategy works in a fact-based, experience-based, and evidence-based manner, and development is based on measurements of truth or reality and not fictitious plans.
The three pillars that support the implementation of empirical process control are
Following are the ways to be dealt with the discord
The principal purpose of an Agile Product Owner is to serve the customer to the development team.
Product Owner Responsibilities include:
The Product Owner Role is an indispensable and essential member of any agile team.
The sprint burndown chart bestows the progress the development team is executing. It is a powerful tool for envisioning progress and the work remaining.
The chart displays:
The Burndown chart allows anyone to view the state of the sprint at any time. Comparing the realistic number of hours available to the actual work remaining depicts the effort that is being planned is in better health than demanded or is in trouble. This information helps to determine about the development team is able to accomplish the targeted amount of user stories and assists in making knowledgeable decisions early in the sprint.
Sashimi is a Japanese word that means a pierced body. It is a Japanese food that consists of fresh meat or fish, sliced into small and thin pieces. Every part is similar in taste when associated with the other pieces.
Sashimi in agile methodology implies that each stage of the software development cycle in a sprint entails requirement analysis, planning & design, development, testing, documentation that is completed or not and the product is available and ready to be displayed, etc.
The daily scrum is a 15-minute time-boxed meeting that is held at the same time, in the same place, each working day. The objective of the daily scrum meeting is to present an opportunity to outline the work for the next 24-hours remove any impediments that might hinder it from achieving the sprint or product goal.
To banish confusion or chaos and keep things productive as much as possible, daily Scrum meetings are held at the same time and same place every day.
Development teams are structured and authorized to establish and control their individual work. It helps to optimize overall efficiency and effectiveness.
Great development teams have the following features:
A Development Team is a group of individuals working collectively to develop and deliver the product increments. The development team includes software engineers, architects, programmers, analysts, system admins, QA experts, testers, UI designers, etc.
Following are the roles and responsibilities of the development team:
The Development Team builds the product and the team is cross-functional