Agile Testing

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:

1. When the requirements are not clear. The client is confused and has no clarity on the business case.
2. Client expects quicker release than the competitor, and late release may lose the advantage of MVP.
3. Client is not clear with the requirements and doesn't have clarity, or a vision for the product.

Sprint Definition: 

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.

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:

User stories:

1. They are easy for anyone to understand
2. User stories can fit in sprints whereas full features can’t
3. User stories help the team to create and progress well in the creation of the MVP.

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. 

Tasks Benefits: 

1. User stories are broken into small manageable units 
2. Team members complete the tasks without feeling overwhelmed 
3. They can easily identify the tasks created on the 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. 

1. Collecting servers or hardware resources for the project 
2. Constructing the team 
3. Elaborating the primary backlog items 
4. Creating Application Architecture design 

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: 

• Functional: Inspects story by decomposing it and identifies risks 
• Technical: Defines the impact of a story or task to understand the technical necessary design. 
• Exploratory: Explores organizational impacts for a particular story. 

The principal roles are

• Scrum team: The Scrum team constitutes of people who work collectively to achieve the best outcome for any given task. The product is created by a dedicated Scrum team.
• Scrum Master: The Scrum Master is the individual who is responsible for the proper working of the entire team. The Scrum Master is a leader and a coach. It is his or her responsibility to assure that the team operates at their best, being productive and meeting the end sprint goal. Scrum Masters are leaders and facilitators who remove any impediments in the way of progress and smoothen the workflows.
• Product owner: The duties of the product owner involve the delivery of a comprehensive and lucid picture of the product. He or she also conveys the same idea to the team.

An Impediment keeps the team away from getting work done and this slows down the velocity.  

Impediments appear in various forms: 

1. Technical debt 
2. Bad boss 
3. Individuals who don’t understand agile  
4. A hurricane 
5. Power outage 
6. Lack of understanding of automated testing 
7. The matrix organization 
8. Team working on more than one release at the same time 
9. The insufficient skill of the team 
10. Unresolved technical issues 
11. Lack of DBA skills within the Team 
12. Need to refactor the Architecture 
13. Technical impediments 
14. Blockers to particular stories 
15. Organizational impediments 
16. Resource issues 

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  

1. Planning 

A plan describing all aspects of the UAT is pulled up. 

1. Test cases designing 

Test cases are designed to cover all the functional scenarios of the software in real-world usage.  

1. Selection of testing team 

Testing team made up of real-world end-users is created. 

1. Documenting test cases and execution 

The team executes test cases, bugs and comments are logged. 

1. Bug fixing 

The software development team fixes the listed bugs. 

1. Sign-off 

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. 

For example 

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? 

• The daily stand-up is held among all team members and is roughly for 15 minutes. 
• Each member has to answer three important questions 
  • What did I do yesterday? 
  • What will I do today? 
  • Any impediment I am facing and any solutions. 
• The daily stand-up is for status update only not for team discussions. Members should schedule meetings at a different time if they need to discuss issues. 

Importance of Stand-up Meeting 

Following are the benefits of having stand-up meetings 

1. The agile team can evaluate the progress and can commit to actions, as required, for each iteration 
2. Each team member informs the others about their commitments and everyone is aware of the same 
3. It provides visibility to the team if there are any changes in the schedule or any delays.  

Stand-up meeting Audience 

1. Scrum Master, Product Owner, and the Delivery team should attend the meeting 
2. Stakeholders and Customers can attend in the meeting as observers 
3. Scrum Master has the responsibility of taking notes and noting down queries of each team member. 

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. 

1. Identify and prioritize the tasks that went well. 
2. Identify and prioritize the tasks that didn’t go well. 
3. Identify possible amendments. 

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. 

Definition 

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: 

1. Backlog grooming (product backlog refinement) 
2. Sprint planning 
3. Daily scrum 
4. Sprint review 
5. Sprint retrospective 

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:

1. Expedites communication and collaboration within the teams.
2. Multiple teams can view the bigger picture of the project and how sprints would affect the teams.
3. Depreciates the risk of the team's work which is negatively impacting each other.
4. Addresses problems of teams and makes course corrections, if essential.
5. Optimizes the workflow within the project.

Automation testing is encouraged for testing on Agile projects because of the following reasons: 

1. Agile methodology encourages Incremental Development. Agile teams have only a few weeks to gather requirements, implement code changes and test the changes. If everything has to be done manually then teams may fall short on deadlines. 
2. Agile projects do not have the complete set of requirements up front. The requirements elaborate with time and often change depending on customer priorities, market trends etc. If everything has to be done manually then teams may fall short on deadlines. 
3. Agility demands early and continuous testing. Agile testing stretches to the newly added code, and code from previous iterations as this ensures prior functionality is not disrupted due to the recently added functionality. Testers face lots of pressure and this can affect the quality of the product. Automating testing will allow testers to have more time in hand for exploratory testing. 
4. Automation testing allows testing the code quickly with a conventional suite of test scripts. This gives the tester more time to react in case the code is not up to expectations. 
5. Automation in testing allows automating other testing activities like data set up, test result validation, and creation of test reports. Frequent code deployments can be automated and this allows testers to focus more on testing. 
6. Automation testing allows detailed and exhaustive examination of the code. This ensures code quality. 

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:

Planning Poker

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.

T-Shirt Sizes

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.

Dot Voting

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.

Large/Uncertain/Small

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.

Affinity Mapping

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.

Ordering method

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.

MVP 

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.

MMP 
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: 

1. What did you do yesterday? 
2. What will you do today? 
3. Any issues and impediments 

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. 

Remove roadblocks 

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. 

1. Sprint 1: 3 user stories x 8 story points = 24 
2. Sprint 2: 5 user stories x 8 story points = 40 
3. Sprint 3: 7 user stories x 8 story points = 56 

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: 

1. Defines the concept and strategy 
2. Provides a guiding document for accomplishing the strategic goal 
3. It helps the internal stakeholders to be aligned 
4. Expedites discussion of opportunities and scenario planning 
5. Helps in communicating with external stakeholders, including customers 

Product RoadMap contents include 

1. Theme 
2. Epic 
3. User Stories 
4. Tasks 

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: 

1. A better technical solution is observed that makes the current technical solution outdated. 
2. A major change in technology. 
3. Market forces the current work as obsolete. 
4. Primary and critical external changes refute the Sprint Goal or the Product Goal 

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: 

1. Handle backlog with a summary and straightened structure 
2. Brainstorm, review, and prioritize user requirements in a collaborative path 
3. Control activities and responsibilities and distribute them into epics or user stories in an orderly manner 
4. Classify and prioritize user actions and user tasks, or dig down to improve them into relevant epics or user stories 
5. Maintain user stories online for both remote and co-location environments

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 

1. To be careful from day one 
2. Clearly understand the requirements and vision of the client 
3. Understand and gather the project requirements 
4. Introduce a system of changing the scope 
5. Watch and guard against gold plating 
6. Always use online project management software for efficient handling of all the processes 
7. Always be careful and know when to say no 
8. If we can’t say no to the customer who is loyal find out some other alternatives 

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 

1. Builds trust 
2. Empowers team 
3. Supports and encourages them to achieve the next level 
4. Is ethical and caring 
5. Is humble and socially aware 

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  

1. Assisting people/ team 
2. Listening to grievances of team 
3. Spending time with the team, to train and inspire them 
4. Politely drawing out their mistakes and helping them improve  

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: 

• Actionable – Actionable item i.e. (doable) by the team? The team should be aware of what they require to do, and can they do it now?  
• Refined – Item within a process of refinement before sprint planning. The team should have a common understanding of what the item is and how it would be completed? 
• Value – The business value of the item and what is the value to the end-user? The team should have a clear vision of the value of the item that would be developed 
• Estimated – Item estimated by the team and the item accepted to be of a size that the team is comfortable that it can be completed within the timebox of a sprint 
• Acceptance criteria – Item that has got clear acceptance criteria 
• Demo – Team understands how they would demo the item or present it in the sprint review once concluded? 

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  

• Transparency: Transparency can be achieved by tools such as Product Backlog, Task Boards, Burndown charts, Daily Stand-ups, Retrospectives, Definition of Done, Sprint Reviews, etc. It allows visibility with regards to the progress of work and team 
• Inspection: The artifacts must be regularly examined and progress towards a purpose or goal should be detected to avoid undesirable variances. 
• Adaptation: It always embraces and Adapts variations or changes to constantly improve. Adaptation implies to have changes that does not work or what could work better. 

Following are the ways to be dealt with the discord 

1. The problem’s origin or the root cause demands to be recognized/ identified and addressed 
2. Full control should be established 
3. Disperse the difference and disagreement  
4. Spotlight on areas that complement the project 
5. The common agreement requires to be authorized to guide the team 
6. Performing, continuous monitoring, and providing complete visibility to the team is very important 

The principal purpose of an Agile Product Owner is to serve the customer to the development team.  

Product Owner Responsibilities include: 

1. Managing and creating an evident and visible product backlog. The product owner then prioritizes a list of specifications for prospective and future product development. 
2. Swapping the order of items in the product backlog. 
3. Conveniently available to the development team at any time to answer every question that team members have concerning the customer’s needs and views of how the team is completing a product feature. 

 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: 

1. The outstanding work on the first vertical axis 
2. Time, in days, along the horizontal axis 

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: 

1. Development teams are self-organizing and no one teaches them how to turn product backlog into Increments conceivably releasable functional products. 
2. Teams have all the abilities and skills that are necessary to create a product increment 
3. Individual team members may have specialized abilities and areas of focus, but responsibility or accountability belongs to the development team as a whole. 

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

1. The team has all the expertise essential to deliver the potentially shippable product of each Sprint
2. They are self-organizing, with a high degree of independence and accountability.
3. They decide and plan out items to be built in a Sprint.
4. They are a cross-functional and self-organizing team that owns the mutual accountability of generating, creating, testing, and delivering the product increment.
5. The team doesn’t have any manager to lead since decisions are taken collectively by the development team.