Agile – Scrum – Digital Resume

Stages in a traditional Waterfall method of software development?

In the traditional waterfall approach, the software development is done in a sequence of phases such as:

Detailed requirement phase: In this phase, the complete set of requirements are captured.
Design phase: We will complete the high-level design, low -level design, etc.
Development phase
Testing phase
User acceptance testing &
Release

Challenges with traditional software development methods?

Mistakes can creep in: for example, requirements may keep changing as the development progresses,
Development may take too long: or at the end, to keep the schedule, we may have to skip some tests, knowingly or by mistake.
It is a long time period, from the requirements to the delivery, we don’t realize any value until the end of the project, and when we realize it, the customer needs may not remain the same.
This approach Leaves the testing until the end, mistakes are detected late, and it will be costlier to fix.
We don’t seek approval from the stakeholders until late. There is no frequent interaction with the customer, and when we show them the product, it might not be the right product for them.
The planning is done and fixed early in the project, and we are managing the project to the plan. There is a heavy dependency on the plan. This traditional approach is heavily reliant upon a project manager driving the way.

What is Agile?

Agile is a philosophy or a mindset, driven by values and principles, which influence the processes, methodologies and frameworks in an organization.

In the year 2001, a group of 17 methodologists representing different methodologies like Extreme Programming, Scrum, DSDM, Adaptive Software Development, etc.

There are 4 important values of Agile:-

Individuals and interactions over processes and tools:
- Processes are good but, we should not underestimate the power of interactions and face to face conversations.
- We are not doing any factory work, where a machine can produce n items in given time.
- We are in a knowledge industry, where the focus should be on empowered, self-managing, cross -functional teams.
- This doesn’t mean that agile is against the processes and tools. They are required, but they should support these interactions. They are not for replacing the interactions.
Working software over comprehensive documentation:
- Traditionally we rely a lot on documentation.
  - We have a requirement phase, where we created and signoff the requirements.
  - Then, high-level, low-level designs create a detailed design document.
- All these are part of our project execution and have weights associated. So, we will say that a percentage of work is done.
- But we have not actually delivered anything that can be used by the end -user.
- Our aim is to deliver value to customers, not a big load of documents.
  - Working software should be our primary output and measurement of our progress.
- It doesn’t mean that we should not document. We should have minimum required documents.
- Another issue is maintaining this huge set of documents.
- We have a detailed design spec, and many times towards the end of the project, we find it to be obsolete because we don’t maintain it.
- So, go for minimum documentation, which is properly maintained.
Agile talks about collaboration; do we need detailed contracts and agreements?
- Customer collaboration over contract negotiation, what do we do traditionally? Customer gives as the requirements, and we give them the product.
- In other words, the customer throws the requirements over the wall, and we throw the product back.
- In agile, Customers become a part of the development process. Customer and vendor together try to serve the end -user.
- Agile never says that we should not have a contract, it is very important, and it facilitates everything.
- It gives us the authority to do the work, and it guides us. But it should be flexible enough to support close collaboration among all parties.
Do we have a project plan in agile? Responding to change over following a plan
- We have a big project, we plan it through completion, we have a sequence of tasks, we have the critical path, leads and lags, Early start date, late finish dates, and so on.
- We start analyzing variance and we consider changes as an exception.
- In Agile, changes are expected.
- We don’t create such long detailed plans.
- We have a road map, an overall plan for a long time and a detailed plan for a short future.
- We don’t create a detailed plan on something that we are not sure about.
- It is like we walk for a small distance, stop, look around and cover another distance.
- We plan in the last responsible moment. We do plan, but follow, kind of, rolling wave planning.

That is, while there is value in the items on the right, we value the items on the left more. Agile is not against processes, documents, contracts, or plans. But there are other items that we value more.

What are the 12 principles behind Agile?

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- We have discussed the manifesto items “Working software over comprehensive documentation”.
  - What customer needs is value, the working software, not a set of documents.
  - We proceed in a series of iterations and deliver Increments frequently.
Welcome changing requirements, even late in development.
- Agile processes harness change for the customer’s competitive advantage.
- We have discussed a manifesto item, “Responding to change over following a plan”.
- The agile approach strives to accommodate changes as efficiently as possible while maintaining an awareness of its consequences.
- Everyone agrees that constant feedback is great but often ignores that the result of accepted feedback changes.
- Agile believes facilitating change is more effective than attempting to prevent it.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- We frequently deliver in shorter periods.
- This helps us to accommodate changes, as per the changing values and customer feedback.
Business people and Developers must work together daily throughout the project.
- The keyword over here is daily.
- It is no more throwing the requirements over the wall.
- We work together with businesses and deliver value to the end customer.
- The business gives us the direction, and teams deliver the value.
Build projects around motivated individuals.
- Give them the environment and support they need, and trust them to get the job done.
- Great processes with state-of-the-art tools don’t guarantee success.
- It is motivated, self-organizing teams that define success.
- We should provide them with support and trust them.
The most efficient and effective method of conveying information to, and within a development team is, face-to-face conversation.
- There is a famous statement ” knowledge cannot be transferred by getting it out of people’s heads and putting it on paper”.
- The best and most effective way of communication is face to face conversation.
- People interacting with each other comes out with more valuable results.
Working software is the primary measure of progress.
- We had discussed this point in detail.
- It is the value we deliver, not the documentation, that defines success.
Agile processes promote sustainable development.
- The sponsors, Developers, and users should be able to maintain a constant pace indefinitely.
- “The keyword here is a constant pace indefinitely.
- It is not working 24/7 from the beginning and tried out towards the middle.
- It is not keeping all the work till one month before release.
- It is all about maintaining a constant pace that can be sustained over a long period of time.
Continuous attention to technical excellence and good design enhances agility.
- Design cannot be a purely up-front activity to be completed before construction.
- Instead, design is a continuous activity that’s performed throughout the project.
- Each and every iteration will have design work.
- But our design must be flexible and efficient to accommodate the changes.
Simplicity–the art of maximizing the amount of work not done–is essential.
- We make it simple.
- We try to achieve maximum value with minimum work.
- We avoid unnecessary complexity both in -process and in value.
- We concentrate on delivering value, and we will try to avoid or postpone activities with lesser value. And concentrate on the core activities.
The best architectures, requirements, and designs emerge from self-organizing teams.
- “It is multiple brains works in a synergic way.
- They organize themselves for better results with the visibility that they have.
- And the results emerge from this self-organizing group.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- “This talks about the inspect and adapt aspects.
- The team evaluates their performance, retrospect and comes out with ideas to improve.

Agile Software Development

Agile software development is a conceptual framework and consists of a group of software development methods, based on an iterative and Incremental development approach, where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams.
It promotes adaptive planning, evolutionary development, and delivery, as a time-boxed iterative approach, and encourages rapid and flexible responses to change.
Agile is an umbrella term for different methods such as XP, Scrum, and DSDM.

Iterative software development? What is Incremental & Iterative development?

Iterative Software Development

In the iterative model, the entire development is split into a number of parts.
Instead of having a long single phase, the development happens in different smaller iterations.
Iterative development breaks down development of a large application into smaller chunks.
In iterative development, the software is designed, developed, and tested in repeated cycles.

Incremental Software Development

Incremental model, the development happens in an Incremental way.
Instead of delivering all at once, we start with an initial one and keep adding Increments to it.
The Incremental build model is a method of software development where the product is designed, implemented, and tested Incrementally, that is, a little more is added each time until the product is finished.

Difference b/w Incremental and Iterative SD

Incremental Development – Part by Part
- Builds the software in parts: Incremental development focuses on building the software piece by piece. Each increment is a fully functional part/unit of the final product, adding new features or capabilities with each iteration.
- Each increment is a functional unit: Even if not the complete product, each part delivered is functional and usable.
- User feedback: Allows for user feedback on each increment, enabling adjustments and refinements.
- Final product: The complete system is delivered after the final increment, where all increments are integrated.

Iterative Development – Continuous Enhancements
- Iterative development focuses on evolving the software through repeated cycles (iterations), refining and enhancing the software with each cycle.
- Cyclic process: The development process is repeated with each iteration, improving the software progressively.
- Refinement through repetition: Each iteration builds on the previous ones, improving functionality, performance, and quality.
- Work on the whole system: Each iteration might involve reworking and refining different parts of the system.
- Feedback-driven: Feedback from each iteration is used to make improvements in the next cycle.

What is a “Self-Organizing Team”?

Self-organizing teams plan and manage their own work on their own. They are not directed by someone outside the team.
Self-organizing teams decide how best to accomplish their work rather than being directed by others outside the team.
Teams are structured and empowered by the organization to organize and manage their own work.

What are Cross -Functional Teams?

A cross-functional team has the right mix of all required skills to successfully complete their work.
A cross-functional team is a group of people with different functional expertise working toward a common goal.

What is Adaptive Planning?

In traditional software development, planning is predictive. The plan is defined at the beginning of a project and then managing the project to the plan.
In Adaptive planning, we define an overall plan at the start, but it is not frozen.
Once work starts, the plan may change to adapt to the new learnings and changes around us based on delivery and changes in the requirements for each iteration.

Key benefits of Agile?

Accelerate time-to-market : Agile delivers the right scope at the right time, not all at once – The most important features are delivered earlier than later. By delivering the right scope at the right time, not all at once, it is better aligned with business priorities.
Increases project transparency and visibility: by having multiple iterations of the end-to-end development cycle rather than one iteration.
Welcome changing requirements: It addresses evolving requirements and reprioritizes as needed.
Reduce risk and overall costs: with short delivery cycles and testing early and often to identify potential issues early in the project.
- Short delivery cycles
- Early testing
- Early customer feedback
- Continuous delivery
- Prioritization influenced by risk and value
- High visibility – risk identification.
Business and Developers work together: throughout the project, it Improves collaboration and alignment with business organizations.
Customer Satisfaction:
- There is more visibility in the development process.
- Agile methods facilitate early and continuous customer feedback.
- Welcome changing requirements, even late in development.
- Agile processes harness change for the customer’s competitive advantage.

How does agile handle changes in requirements?

Agile processes harness change for the customer’s competitive advantage.”
- We have a high-level plan for a long time and a detailed plan for a short period.
- Plans and processes are flexible enough to accommodate changes.
- Start with an initial set of requirements and rest at a high level.
- Requirements are defined as development progresses.

Differences between the agile and traditional ways of working?

Area	Traditional Approach	Agile
Planning	Planning is a one-time activity	Planning is done at different levels. We will have Initial up-front planning at the start and ‘Just-In-Time’ planning in iterations.
Who does the planning?	Project manager plans for the team	Team is empowered and participates in planning
Requirement Gathering	Detailed requirements are captured and frozen up-front	We have high-Level requirements to start with, and requirements evolve as the project progresses.
Requirement Documentation	Huge requirements documentation, a lot of text at different levels	Requirements are captured in the form of User Stories or Use Cases in a simple way.
Client Collaboration	Limited client collaboration after requirements definition.	Collaboration with the client throughout the project lifecycle.

Are there any disadvantages of the Agile model?

There are situations where documentation is ignored completely.
Agile demands more time and energy from everyone because developers and customers must constantly interact with each other. At times, it is difficult to ensure this involvement.
As agile welcomes change and new requirements, the project can become ever-lasting because there’s no clear end, and scope creep may happen.
At times an overall plan, in the beginning, may not be enough for the clients who work on a specified budget or schedule. They can’t predict how much the project will actually cost.
Teams can get focused on delivering new functionality at the expense of technical debt, which increases the amount of unplanned work.

When should we use waterfall over Scrum?

We may prefer waterfall if
- The requirements are very clear and frozen
- The customer won’t demand any changes
- The customer is not ready for frequent interactions
- The project is small
- Time to market is not important

What is JIT planning?

JIT stands for just in time.
In this approach, we have a high-level plan for a long duration, detailed plan for a short Duration.
Detailed plans are created at the time they are needed, not months in advance. Decisions are made at the last responsible moment. This reduces re-work and re-plan.

What are the different touchpoints between development and business?

The agile principle says, “Business people and Developers must work together daily throughout the project. “So, the answer is throughout the development period, not only at the specific gates.
Agile methods have mandated some prescribed events to ensure these interactions. These events don’t limit the collaboration, and they only define the minimum required ones.

Which is the most effective communication tool used in agile?

Remember the value: “Individuals and interactions over processes and tools”. So, the most effective way will be face to face conversations. Tools can’t replace this, but they can support this communication.

What is the reasonable rate at which productivity increases between iterations?

We should not put any hard rule on the rate of increase in productivity. The aim is to maintain a sustainable pace. Teams, as they progress through iterations, will reach an optimal level which they can maintain indefinitely.

How design and architecture are handled in agile projects?

Design and architecture evolve as the product is being built. We start with a simple and extendable design and improves it as we go along. Start with the simplest architecture that can possibly work and keep improving it.

Which role will monitor and suggest improvements?

Agile teams are self-organizing, Self-managed. They inspect and adapt. The agile principle states, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly “. There may be variations in the way by which this is implemented in some agile methodologies. But the basic principle remains. It is the self-organizing, self-managed teams that monitor and adapt.

What is meant by “the art of maximizing the amount of work not done”?

The aim is to deliver fast and maximize the value created for the customer.
To achieve this, we should identify the items that do not add value or has lesser value and those which will add more value.
Our goal is to produce the highest value by doing the fewest number of items.

Other Agile Methodologies

Scrum still remains as the most used agile methodology. Also, Scrum, Scrumban, and Scrum XP Hybrid together make the major part of agile methodologies used.

SCRUM

Is SCRUM an acronym?

No, Scrum is not an acronym. Scrum is a framework used in agile project management and software development. It is a term derived from the sport of rugby and was chosen by its founders to reflect the idea of a team working closely together to move the ball down the field collaboratively. Scrum does not stand for any specific words or phrases; it’s simply the name of the framework itself.

So what is SCRUM?

Scrum is a light weight framework that – helps people, teams and organizations generate value by building adaptive solutions for complex problems. A framework with which people can address complex problems using adaptive solutions, while productively and creatively delivering products of the highest possible value.

Scrum is focusing on Incremental, iterative development. Iterations are called Sprints.
It depends on self-organizing, cross-functional teams, delivering a potentially shippable Increment at the end of every Sprint.
Scrum works with Iterations or Sprints of max one-month duration.
It ensures the continuous flow of value to customers through iterative, Incremental development and delivery.
It follows Adaptive rather than predictive planning.
It promotes collaboration among all parties involved.

The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it, rather than fixed rules.

Rules of Scrum guide their relationships and interactions.

What is the difference between Agile and Scrum?

Scrum is one of the Agile approaches and is the most used agile framework.
Agile is an umbrella term for several iterative, and Incremental software development approaches, including Scrum.

Scrum is founded on empiricism and lean thinking

Empiricism asserts that knowledge comes from experience and making decisions based on this experience and what is observed
Lean thinking asserts taking decisions keeping in mind reduction of wastages and focusing on the essentials.

Scrum employs an iterative, incremental approach to control risk and to optimize predictability.

What is empirical process control?

Scrum is founded on empirical process control theory.
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
The empirical model of process control provides and exercises control for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs.
This is done through frequent inspection and adaptation.

Pillars of empirical control:

Transparency
Inspection
Adaptation.

How does Scrum increase transparency?

Scrum is built on empirical pillars of Transparency, Inspection, and Adaptation.
Scrum makes the work visible to all stakeholders.
Scrum Artifacts enhances this visibility.
Scrum has small delivery cycles and prescribed events that enhance transparency.
For example, product demos and reviews keep all informed about the current state.
The team follows tools like Acceptance Criteria, Definition of Done, Definition of Ready, etc.

When should we inspect?

We do inspect and adapt throughout the duration of the project.
Scrum Guide says “The Scrum Artifacts” and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.
Their inspection should not be so frequent that inspection gets in the way of the work.

Lean Principles

Definition: Lean is a methodology originally derived from manufacturing principles, particularly from the Toyota Production System. It focuses on maximizing value by minimizing waste and continuously improving processes. In the context of Scrum and software development, Lean principles emphasize efficiency, customer value, and the elimination of non-value-added activities.

Key Lean Principles Applied in Scrum:

Eliminating Waste:
- Definition of Waste: Waste in Lean refers to any activity or resource that does not add value to the customer or the end product. This includes unnecessary features, delays, rework, and inefficient processes.
- Application in Scrum: Scrum teams aim to reduce waste by continuously refining the Product Backlog to ensure that only valuable items are worked on. The focus is on delivering only what is necessary to achieve the Sprint Goal, thus avoiding unnecessary work and complexity.
Delivering Value Quickly:
- Definition: Lean emphasizes delivering value to customers as quickly as possible. This involves producing small, incremental improvements rather than waiting to deliver a large batch of features.
- Application in Scrum: Scrum uses Sprints to produce increments of the product at regular intervals. Each Increment should provide some value to the customer, allowing for feedback and adjustments to be made early and often.
Empowering Teams:
- Definition: Lean promotes the idea that those who are closest to the work are best positioned to make decisions about how it should be done. Empowering team members improves efficiency and responsiveness.
- Application in Scrum: Scrum encourages self-organizing teams where Developers decide how best to accomplish the work. This autonomy supports more efficient decision-making and fosters a sense of ownership and responsibility.
Continuous Improvement (Kaizen):
- Definition: Kaizen, or continuous improvement, is a core Lean principle. It involves regularly seeking ways to improve processes, reduce waste, and enhance value.
- Application in Scrum: Scrum incorporates regular opportunities for reflection and improvement through ceremonies like Sprint Retrospectives. Teams review their performance, identify areas for improvement, and implement changes to enhance their processes and productivity.
Building Quality at Every Step:
- Definition: Lean emphasizes that quality should be built into the process rather than inspected in later. This means addressing quality concerns as they arise rather than relying on final inspections.
- Application in Scrum: Scrum ensures that quality is maintained by following the Definition of Done (DoD) for each Increment. Testing and quality assurance are integrated into the development process, ensuring that each Increment meets the required standards before it is considered complete.

What are the Seven Types of Wastes?

Seven Types of Wastes and their counterpart from Software development :
1. Excess Inventory – partially done work
2. Overproduction – Unwanted features
3. Over Processing – Re-Learning
4. Transportation – Excess Hand-Offs
5. Waiting – Delays
6. Motion – Task Switches
7. Defects

What are Scrum values?

Commitment:
- The Scrum Team commits to achieving its goals and to supporting each other.
Focus:
- Their primary focus is on the work of Sprint to make the best possible progress toward these goals.
Openness:
- The Scrum Team and its stakeholders are open about the work and the challenges.
Respect:
- Scrum Team members respect each other to be capable, independent people and are respected as such by the people with whom they work.
Courage:
- The Scrum Team members have the courage to do the right thing, to work on tough problems.

What is a Sprint?

Every software project is intended to convert a number of requirements into working software, an Increment, or a change.
Scrum follows an iterative and Incremental approach.
The work is carried out in multiple iterations called Sprints.
Sprint is a Time-boxed iteration, during which a potentially releasable product Increment is created, Design, Build and Test activities are performed within Sprint.
Sprint Duration is a Maximum of one month.

Roles, Ceremonies, and Artifacts in SCRUM?

As we have already seen, there are 3 roles, 3 artifacts and 4 ceremonies in Scrum.
Roles:
- Product Owner
- Developers, and
- Scrum Master.
Ceremonies:
- Sprint Planning
- Daily Scrum
- Sprint Review, and
- Sprint Retrospectives.
Artifacts:
- Product Backlog
- Sprint Backlog, and
- Increment.

The Scrum Team: Roles

The Product Owner, the Developers, and the Scrum Master, together referred to as the Scrum Team.
The Scrum Team is small enough to remain nimble and large enough to complete work within a Sprint, typically ten or fewer people.

Product Owner

The Product Owner is responsible for maximizing the value of the product, resulting from the work of the team.

He owns the requirements.
Detailing backlog items
Ordering or prioritizing them to maximize the value, and
Clearly communicating them to the team.
They develop and explicitly communicate a clear Product Goal.

2. The Scrum Master

The Scrum Master is a true leader, a facilitator, and a coach.
The Scrum Master is responsible for promoting and supporting Scrum.
Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
He or She ensures that the Scrum is understood and enacted by the team.
He or She facilitates the Scrum events as required.
Scrum Master makes sure the impediments for the development are removed.

3. Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment for each Sprint.
They decide how they are going to create a shippable Increment at the end of the Sprint.
They have all the skills required to convert the selected requirements into the “done” shippable Increment.
The specific skills needed by the Developers vary with the domain of work.
Developers are always accountable for Creating a plan for Sprint.
This will be in the form of Sprint Backlog.
They are accountable for the quality of the product.
Every day they inspect and adapt their plan to maximize the chances of achieving the Sprint Goal.

Sprint Ceremonies

1. Sprint Planning & Sprint Goal

Sprint starts with a Sprint Planning meeting. This is time – boxed to 8 hours for one-month Sprints.
For shorter sprints, it is usually shorter.
The Product Owner explains the Product Backlog items and explains the expectations.
The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
Developers select items for upcoming Sprint based on their capacity.

[Team velocity: Team velocity, the size of work that they have successfully delivered in the last Sprint ]

Team velocity, the size of work that they have successfully delivered in the last Sprint, helps as a guideline while deciding their capacity for the next Sprint. In other words, what is going to be included in the Sprint is decided here.
The team creates an initial plan for converting the selected items to a shippable Increment.
This may be in the form of technical tasks for each selected item, or maybe only for items to start with. This explains how the team is going to achieve the Sprint Goal.

2. DAILY SCRUM

Every day, Developers do a Daily Scrum meeting.
- This is of 15 minutes duration.
- This takes the form of a stand-up meeting, where they collaborate and decide on actions to be done before the next Daily Scrum.
Normally, it takes a form where every member answer three questions.
- What have I done since the last daily scum for achieving the Sprint Goal?
- What am I going to do till the next Daily Scrum?
- Do I see any threats for the Sprint Goal?

3. SPRINT REVIEW

At the end of the Sprint, the Scrum team, and other stakeholders, as invited by the Product Owner, conduct a Sprint Review.
This is time -boxed to 4 hours for one-month Sprints.
For shorter Sprints, it is usually shorter.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.
Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done.
This is not just a status meeting. The presentation of the Increment is intended to elicit feedback and foster collaboration.

4. SPRINT RETROSPECTIVE

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
This is time -boxed to 3 hours for one-month Sprints.
For shorter Sprints, it is usually shorter.
There are different methods used for retrospectives.
- For example, the team may try to find out What went well, what didn’t go well, what are areas of improvement.

– END OF ONE SPRINT & BEGINNING OF NEXT

Both Sprint Review and Sprint Retrospective may have an outcome that impacts the next Sprint Planning.
A new Sprint starts immediately after the previous Sprint ends; there is no gap in between.
Scrum teams conduct Sprints one after the other, creating software Increments in an iterative and Incremental way.
As mentioned before, the team create tested and shippable Increment at the end of each Sprint.
It may get deployed as it is or waits for further Increments.
However, the team will keep on producing shippable Increments.

SCRUM Artifacts

Product Backlog

Definition:
The Product Backlog is a dynamic and prioritized list of everything that could be needed in the product. It captures all the requirements, features, enhancements, bug fixes, and any other items needed to deliver a successful product.

The Product Backlog is an ordered list of everything that is known to be needed in the product.
Usually, the items take the form of Epics and User stories.
This is a live document.
The Product Backlog exists as long as the product exists.
Items can be added to the Product Backlog at any time during the project.
It is a Prioritized list of requirements that provide business value for the customer.
The Product Owner is responsible for creating and maintaining requirements.
But the team can contribute to this activity.

Creation and Maintenance:

Creator: The Product Owner is responsible for creating and maintaining the Product Backlog. They gather requirements from stakeholders, customers, and other sources to ensure that the backlog reflects the product’s needs.
Maintenance: The backlog is continuously updated and refined, a process known as backlog refinement or grooming. This involves re-prioritizing items, breaking larger items into smaller tasks, and adding new requirements as needed.

Ordering:

The Product Backlog is ordered based on factors such as business value, risk, and dependencies. Higher-priority items are placed at the top of the backlog to ensure they are addressed first.

Sprint Backlog

Definition:
The Sprint Backlog is a subset of the Product Backlog that is selected for a particular Sprint. It consists of the items that the team commits to delivering during that Sprint and includes a detailed plan on how to achieve the Sprint Goal.

Ownership and Maintenance:

Ownership: The Developers own the Sprint Backlog. They are responsible for keeping it updated throughout the Sprint.
Maintenance: The Sprint Backlog is updated regularly during the Sprint to reflect progress, changes, and new insights. This ensures that the team has a clear and current understanding of the work needed to achieve the Sprint Goal.

Activities:

Design, Development, and Testing: These activities are performed within the same Sprint to create a potentially shippable Increment of the product. This means that the team designs, develops, and tests the features or fixes selected for the Sprint within the time-box of the Sprint.
Flexibility: Developers are expected to adapt their approach as needed to achieve the Sprint Goal, making adjustments to the work as necessary.

Increments

Definition:
An Increment is a concrete step towards achieving the product’s overall goals. It represents a completed portion of the product that has been built and integrated during the Sprint. Each Increment must be done to the quality standards required and is potentially shippable or releasable.

Purpose:

Every Increment builds on the previous ones, adding new features or improvements, which helps to ensure continuous progress and delivery of value throughout the development process.
The Increment is designed to add value to the product. It should be functional and meet the Definition of Done (DoD), meaning that it is complete, tested, and ready for review or release.

Commitments associated with Scrum artifacts?

Each Scrum artifacts contains a commitment.
This increases transparency and helps in creating focus—this helps in measuring the progress.
For the Product Backlog, it is the Product Goal.
For the Sprint Backlog, it is the Sprint Goal.
For the Increment, it is the Definition of Done.

What is a Product Goal? Who creates it?

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
It is part of the Product Backlog and serves as a long-term objective for the Scrum team.
As we have seen early, the Product Owner creates and explicitly communicates the Product Goal.

What is Sprint Goal? Who creates it?

During the Sprint Planning the whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
It is a single objective for the Sprint and part of Sprint Backlog.

What is the Definition of Done? Who creates it?

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
It either exists in the organization or created by the Scrum team.
If it exists in the organization, the Scrum team will follow it as a minimum; that is, they may enhance, not depreciate, it by adding product -specific items.

What are social contracts?

In addition to all these formal ones, Scrum Teams may define a set of ground rules that will help them in delivering as a self-organized, high -performing team.
These are called social contracts. E.g. “No side conversations during stand-ups, everyone pays attention to what’s being discussed”.
Each team will define its rules based on its requirements. This can be captured in any format as decided by the team.

Interaction with business? Scrum team’s access to the stakeholders

The agile principle says Business people and Developers must work together daily throughout the project.
In Scrum, business is represented by the Product Owner.
He coordinates with all stakeholders and represents their views.
He gives the team business direction and maximizes the value of work that the team performs.
Close collaboration with the Product Owner is mandated for the success of Scrum.
Scrum events are designed to enhance these interactions.

How do you coordinate between multiple Scrum teams?

There are different scaling frameworks that exist for multiple-team implementations.
- Scrum of Scrum
- Common Sprint Reviews
- Combined Retrospectives
- Multi -Team Planning
- Common Product Backlog
- Dependency Tracking, etc.

What is a Hardening Sprint? Why and when is it done?

Scrum doesn’t define anything called a hardening Sprint.
There are teams who conduct a hardening Sprint to prepare the product for release.
Activities like the final round of testing, fixing, preparation for deployment are carried out in this.

What is Sprint Zero?

Scrum doesn’t define anything called Sprint zero.
These are teams that conduct a Sprint to prepare for the development of Sprints.
Activities like Team training, initial backlog grooming, initial overall architecture, setting environments are carried out in this.

What is Product Increment in Scrum?

An Increment is a concrete stepping stone toward the Product Goal.
Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
This is termed as one of the Scrum Artifacts.
This is fully tested, approved, and ready for deployment.

Benefits of short – duration Sprints?

Early feedback
Better focus
Easy to respond to changes
Inspect and adapt opportunities,
Frequent and continuous delivery
Reduced risk, etc.

What is the importance of Continuous Integration?

It helps on-time release by detecting bugs or integration errors early.
Continuous integration ensures a stable baseline, even when there are multiple integrations from different teams working in parallel.
It helps to maintain the quality and bug – free state of the code-base.
Continuous integration helps to check the impact of work on branches to the main trunk.
It brings in better coordination and reduces blockers.

Which is the prescribed event that we should not avoid by any chance?

All events are mandatory and equally important.
The Scrum Guide states, “Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

When should we conduct Sprint Retrospective, and why?

Sprint Retrospective should be conducted at the end of the current Sprint, before the next Sprint Planning.
It is easy to remember and reflect on what happened during the Sprint if we conduct it in proper sequence.
The Sprint Retrospective concludes the Sprint.
Action items coming out of Retrospective will have an impact on the next planning.

Why does Scrum recommend co-located teams?

Co-located teams have many benefits, including Effective Communication, Faster Decisions, Reduced Overhead, easy team management, better coordination, Osmotic Communications, More trust, Etc.

Challenges with distributed teams?

Distributes teams face challenges in many areas, including
- Planning / Tracking and Work Distribution will become more complex,
- Team Organization across locations will be challenging,
- Cultural Differences among the team members from different locations,
- Communication, and Collaboration, team members in different Time Zones across the globe,
- Lack of Face-to-Face availability of Product Owner and Business Users with the Project Team,
- Multiple Sign-off layers, delaying development.

How do you address the challenges with distributed teams?

So, we can think of improving the situation by improving communications, better planning and visibility, Right roles, right time, right place, optimize overlap times, Effective team rotations, and use of the right tools.

Business Requirement Documentation

What is a User Story?

A user story is a requirement written from an end-user perspective.
A user story describes functionality that will be valuable to an user.
These are written from the perspective of the customer. It reflects what customers expect from or want to do with the product.
Items in the Product Backlog, usually written in the form of User Stories.
It usually takes the form – “ As a User, I want to do something so that I get this benefit”.

What are the 3 Cs of a user story? – Card, Conversation, Confirmation

Card: indicates that the User Story should be small enough for a single card.
Conversation: talks about the detailing part. Detailing will be a result of further discussions and collaboration. More details will be attached or added to the user story as we go along.
Confirmation: When can we confirm that the User Story is successfully implemented – Usually, it may take the form of the acceptance criteria.

What is a Spike?

Spike is a story or task aimed at answering a question or gathering information rather than at producing a shippable product.
The purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.

Techniques used for splitting user stories?

Large user stories, EPICs must be split into smaller ones to handle them within the Sprints.
There are different approaches used to break up Epics or User Stories:
- Split using CRUD boundaries;
  - CURD stands for Create, Read, Update or Delete,
- Another approach can be Split at System boundaries, where we will define the subsystem boundaries and try to split the stories.
- Other approaches can be Split at Basic or Exception path,
- Split at Workflow steps, or
- Split based on Business Rules variations, etc.

What is meant by the slicing the cake approach?

We split the stories based on functionality, not based on technical layers; that is, all stories will cover all technical layers required for its implementation.
This approach is called – Slicing the Cake.
In other words, we should not split user stories based on architectural layers. It should be done based on functionality.
Each slice should have a part of all the layers.

What is an EPIC?

Large user stories are typically referred to as epics.
Epics generally take more than one or two Sprints to develop and test.
They are usually broad in scope, short on details.
It must be split into multiple, smaller stories before the team can work on them.

What is a THEME?

A theme is a group of user stories that share a common attribute.
They are grouped together for convenience.
For example, we can have a theme, communication.
All stories related to customer communication can be grouped and tracked under this.
Themes are often used to organize stories into releases or to organize them so that
various sub-teams can work on them.

What does INVEST stand for while creating user stories?

Independent
- Independent implies the user story should be self-contained in a way that there is no inherent dependency on another user story.
Negotiable
- It should be Negotiable – Stories are not contracts;
- leave room for discussions.
- More details will be added, or it changes as more knowledge is available.
Valuable
- A user story should be Valuable to users and customers, not Developers.
- It should be written to reflect user or client perspectives.
Estimable
- A user story must have enough details to estimate at required levels.
- Predictions are based on these estimates, so we should be able to estimate them.
Sized Appropriately
- A user story must be Small enough to complete in one Sprint.
- Large stories should be split into smaller ones.
Testable
- A user story must be Testable.
- The “confirmation” attribute that we have discussed earlier must be stated clearly.

Can User Story be Independent?

Ideally, it should be independent.
But this may not be possible at all times.
We should try to fine -tune it as much as possible to minimize dependencies, and there
should be a plan for addressing the remaining dependencies.

Are epics ready for implementation?

An Epic, in general, can be considered as a large User Story that needs to be broken down into smaller user stories.
The scrum team will decide to what extent the stories should be fine -grained, based on the nature of work.
Maybe we can consider an Epic as ready when all user stories derived from it are ready.

What are Acceptance Criteria? Who creates Acceptance Criteria?

Acceptance Criteria is a set of pre-established conditions that the product Increment should satisfy to be accepted by the user.
This will be provided by the Product Owner.
Acceptance criteria are written in simple language.
It defines the conditions of success or conditions of satisfaction.
It provides clear story boundaries.
Acceptance criteria remove ambiguity by forcing the team to think through how a feature or piece of functionality will work from the user’s perspective.
It provides a checklist or template of things to consider for each story and establishes the basis for acceptance testing.

What is DOR – Definition of Ready for a user story? How do we confirm that the user story is ready in all aspects and can be taken up for implementation?

Definition of Ready for a user story confirms that the User Story is ready for implementation.
This can include items like…, story defined, and the business value is clearly articulated.
The story has been assigned with the right amount of Story Points; it is estimated.
The story is clearly understood by the development team.
Acceptance criteria are clear and testable.
Dependencies are identified, and no external dependencies would block the story from being completed.
Business Test Data required to test the story has been identified.
Performance criteria, if any, are defined and measurable.
The story is small enough to be comfortably completed in one Sprint.

What is the Definition of Done? What is the Definition of Done for a user story? Who defines the Definition of Done for a user story?

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.
Definition of Done for a User Story is a set of pre-established conditions for confirming the same as Done.
It is not the same as Acceptance Criteria, but meeting the Acceptance Criteria can be an automatic selection to the list.
If the Definition of Done for an Increment is part of the standards of the organization,all Scrum Teams must follow it as a minimum.
If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriately for the product.
It will be inspected in regular intervals and improved, and it’s not a frozen document.

What can all be part of the Definition of Done for a User Story?

Items in the Definition of Done can include…
- User Story meets the Acceptance Criteria and is reviewed by the Product Owner.
- All code changes are reviewed as prescribed by the quality manual,
- Major findings are closed.
- Code changes are checked in to the “XYZ” branch.

What is the Definition of Done for a Sprint?

There are organizations that define the Definition of Done at the Sprint and release level.
Definition of Done for Sprint confirms that
- All required tasks and other activities for the Sprint are completed.
- Definitions of Done of each single User story, included in the Sprint are met.
- All unit tests are passing, and Product Backlog is updated,
- Product Increment is deployed
- On the test environment identical to the production platform, the performance tests passed,
- All category 1 bugs are fixed,
- Completed User Stories are accepted by the Product Owner,

What is the Definition of Done for a Release?

Definition of Done (DoD) for Release confirms that all required tasks and other activities for the release are completed.
It can include…, but not limited to,
- Code Complete reached,
- Environments are ready for release,
- All test results are green,
- All the acceptance criteria are met,
- QA is done and all issues resolved,
- Green baseline,
- No open issue in build and integration,
- Release documents are ready

Prioritizing Product Backlog

How do you prioritize your backlog? What is MOSCOW?

The final decision on the order of items in the Product Backlog is from the Product Owner; however other roles can influence these decisions.
One of the commonly used models in Moscow, where Backlog items are categorized as
- Must have : is a Minimum Usable Subset.
- Should have:
- Could have,
- Won’t have, but would like in future.
Other approaches for ordering include
- Business Value
- Risk – Based
- Kano Model, etc.
A Product Backlog contains different types of items like story-based work, Task-based work, etc.
In short, everything that is required for the product.
Higher ordered Product Backlog items are usually smaller, clearer, and more detailed than lower ordered ones.
The Product Owner is responsible for maintaining the Product Backlog, but the estimates must come from the people who do the work.

What is DEEP stand for?

DEEP talks about the characteristics of a healthy Product Backlog and stands for
- Detailed appropriately:
  - Product Backlog items must have enough details, based on what is known so far.
- Emergent:
  - It is a live document; it gets updated throughout the life of the product.
- Estimated:
- Prioritized:
  - It is a prioritized list with an estimate based on what is known.

What will be a healthy Product Backlog?

A healthy backlog will be respecting the DEEP criteria.
Items will exist at different levels of detail.
There will be items that are ready for implementation and items which need further refinement.
The list should be prioritized and estimated based on the availability of information.
As good practice teams, make sure there are enough ready user stories for the upcoming “n” number of Sprints.
This number will be agreed upon by the Scrum team.

What is a backlog grooming meeting? Who should attend the backlog grooming meeting?

Product Backlog refinement or Product Backlog grooming is the act of adding detail, estimates, and orders to items in the Product Backlog.
It is an ongoing activity. No time box is specified for this activity, but it should not block Sprint activities. This activity can be used … to write user stories, that is, expand, add more details, etc.
Break down user stories that are too big, improve user stories that are poorly written, estimate backlog items, add acceptance criteria, if not already done.
Look deeper into the backlog to do longer-range technical planning.
A typical Product Backlog Grooming or Backlog Refinement activity can have two parts.
- Concentrate on Requirement Clarification and adding more details to the Product Backlog.
- In the second part, the team will do an estimation for the user stories.

Estimation

What is the cone of uncertainty?

The cone of uncertainty is a graphic depiction of the increased accuracy that is possible for estimates as the details of a project become more known over time.
The initial estimate will be less accurate.
It becomes better as we acquire more knowledge throughout the project duration.

What are different estimation techniques?

Traditional Techniques

Lines of code
Function points
Use Case Points,

In agile, we use techniques like:

Story points
T-Shirt sizing
Ideal days, etc.

What are ideal days or ideal hours?

Ideal Days is an absolute estimation method.
It estimates How long something would take if it’s all you worked on and there are no interruptions for the work.
In Scrum, task -level estimates are usually done in ideal hours.

What is relative estimation?

Relative estimation consists of estimating something, not separately and not in absolute units of time, but by comparison with one another.
It is also done by a grouping of items of equivalent size.
In short, estimation is done in a relative way, in comparison with one another.
T-shirt sizing and story points are two examples of relative estimation.

Explain story point estimation.

Story point is an arbitrary measure used by Scrum teams.
This is used to measure the effort required to implement a story.
It is a relative measure; it is done by comparison.
It estimates how long it will take considering many factors like complexity, uncertainty, risk, etc.
It is a faster way of estimating.
The people who do the work, the development team, are responsible for making this estimate.
A frequently used scale is Fibonacci Series.
Story Points are a unit of measure for expressing the overall size of a User Story, feature, or other pieces of work.
The number of Story Points associated with a User Story represents the overall size of the story.
When estimating with Story points, we assign a point value to each item in comparison with other items.
Larger stories, Epics can have ranges like 100, 200, etc.

How do you decide the baseline for story point estimation?

Story Pointing is a relative estimation method.
It requires a referral point to do the estimates.
Experience teams may have a clear understanding of what a story point meant for them.
When we do it for the first time, we need to create a base.
A story of a reasonably small size will be selected and assigned 1 or 2 points.
Other stories will be compared with this to find its size.
Some companies advocate considering certain hours of effort as a story point.

Explain planning poker.

Planning poker is a method, tool, or activity for estimating using story points.
Usually, it follows the below steps.
- First, the Product Owner provides a short overview of the story to be estimated.
- The team discusses to clarify assumptions and risks, and the outcome of the discussion is updated in the user story.
- Each individual is given a set of cards with the values that are used, usually the cards with Fibonacci numbers.
- Each individual selects a card representing their estimate and lays it down.
- Everyone shows their cards simultaneously by turning them over.
- If there is a difference, People with high estimates and low estimates are given a chance to clarify their estimate, and then the process repeats.

What should we do if there is no consensus in planning poker?

Participants with an estimate at extreme ends will explain the logic behind the estimation.
Product Owner clarifies if there are any points or wrong understanding.
Once the story and expected work are clear, the team estimate again, this process can repeat but can’t go on indefinitely.
If a team fails to get an estimate even after multiple rounds, that indicates there is no single shared understanding of the story or the work related to it.
The story should be parked for further grooming.

Explain T-Shirt Sizing?

T-shirt sizing is a way of relative sizing.
By comparing stories, you can put them in buckets of extra-small, small, medium, large, and extra-large.
Estimating in relative buckets is easier than estimating absolute time or effort.

When and how do you do estimates in Scrum?

Estimation is not a one-time activity.
At early stages at EPIC or Feature, estimates will be at a high level.
Once requirements reach the level of user stories, we will do a relative estimation with story points.
While doing the Sprint Planning, we will create tasks for each story which will be estimated using ideal days or ideal hours.

SCRUM EVENTS

What are different events prescribed by Scrum?

Sprint Planning
Daily Scrums
Sprint Review, and
Sprint Retrospective.

Sprint Planning

What are the different levels of planning in Scrum?

There will be a high-level plan at the release level, based on what is known.
The scrum team does detailed planning while starting a new Sprint.
The work to be done in the Sprint is planned as a result of the collaborative effort of the Scrum team.
Every day the development Team conducts a Daily Scrum where they synchronize activities and create a plan for the next 24 hours.

What is team velocity?

Velocity indicates the past performance of the team.
Generally, it is expressed as the total number of Story points completed in an iteration.
This is the sum of story points for all stories done in an iteration.
Only stories or features that are completely counted.
This Should not be used to compare the velocity of different project teams.
We can use it to compare across iterations for a given team, to understand the trends, and take corrective actions.
It helps us in refining the release plan.

How do we use velocity in release planning?

We have the velocity, and we know the total estimated size of the Product Backlog.
So, a simple division will give the number of iterations required.
We should understand that these are predictions based on what is known till now.
These are not frozen plans and will change as more information is available.
A simple calculation can be as follows… Assume we have a total size of 400 story points in the Product Backlog and a velocity of 20 story points. That means we need 20 Sprints to complete the identified items in the Product Backlog.

When should we do Sprint Planning? Whom all should participate in Sprint Planning? Who does Sprint Planning? What is the Duration of Sprint Planning?

The work to be performed in the Sprint is planned at the Sprint Planning.
This plan is created by the collaborative work of the entire Scrum Team.
The Scrum Master ensures that the event takes place and that attendants understand its purpose.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
For shorter Sprints, the event is usually shorter.
Sprint Planning is the first activity of the Sprint.

What are the Inputs for Sprint Planning?

The inputs to Sprint Planning are the Product Backlog, where we have the ordered, estimated list of requirements.
The latest product Increment, we should know what we have done so far.
The projected capacity of the Development Team during the Sprint assesses the availability of the team.
We will consider leaving plans, holidays, etc. Past performance of the Development Team, the current speed, performance, or in other words, the velocity of the team.

Sprint Planning answers the following questions.

Why is this Sprint valuable?
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work need to deliver the Increment be achieved?
Sprint Planning decides why we Sprint,
What can be delivered and how it can be delivered, the why, what, and how aspects of the Sprint.

Explain the Sprint Planning process. What is Sprint Goal?

In the first part of Sprint Planning, the Product Owner proposes how the product could increase its value and utility in the current Sprint.
The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
The Sprint Goal must be finalized prior to the end of Sprint Planning.
The Sprint Goal is the single objective for the Sprint.
The Sprint Goal is an objective for the Sprint that can be met through the implementation of selected Product Backlog items.
It provides guidance to the Development Team on why it is building the Increment.
By the end of the Sprint Planning, the Development Team should have an idea of how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

In the second part of Sprint Planning, the Scrum team decides what can be done this Sprint?
The usual process includes, The Product Owner explains the objective that the Sprint should achieve and discusses the Product Backlog items that, if completed in the Sprint, would achieve this objective.
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.
The Scrum Team may refine these items during this process, which increases understanding and confidence.
The team decides How will the chosen work get done?
Developers decide how it will build this functionality into a “Done” product Increment during the Sprint.
The Developers usually start by designing the work needed to convert the Product Backlog into a working product Increment.
How this is done is at the sole discretion of the Developers.
Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.
The Product Owner can help this process by clarifying the selected Product Backlog items and make trade-offs.
If required Development Team re-negotiates the selected Product Backlog items with the Product Owner.

What is Sprint Backlog? When do we update Sprint Backlog? Can Sprint Backlog grow in size?

The Sprint Goal + The Product Backlog items selected for this Sprint + the plan for delivering them is called the Sprint Backlog.
Developers are responsible for creating and maintaining the Sprint Backlog.
The plan usually takes the form of engineering tasks and other work items for meeting the Definition of Done for the selected items.
These tasks are usually estimated in hours or days.
Team start with known tasks at the time of Sprint Planning.
As development progresses, tasks may get added, and Sprint Backlog can grow in size.
It is a live document; Developers keep updating it throughout the Sprint duration.
As a good practice team, make sure that Sprint Backlog is updated before or during Daily Scrum.
At any point in time, the total estimated effort for unfinished tasks in Sprint Backlog gives the amount of identified work that remains in the Sprint.
As Sprint progresses, new tasks may get added, resulting in a temporary increase in remaining effort.

Daily Scrum Planning

How is daily planning done in Scrum? Who conducts Daily Scrum? What is Daily Scrum?

The Daily Scrum is a 15 minutes time-boxed event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
Daily Scrum is conducted by Developers, and Scrum Master makes sure this event happens effectively.
If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Usually, it takes the format of three questions.
Every team member answers three questions.
- What did I do yesterday that help the team meet the Sprint Goal?
- What will I do today to help the team meet the Sprint Goal?
- Do I see any impediment that prevents the team or me from meeting the Sprint Goal?
Three questions format is not mandatory, but it was successfully followed by many teams.

What are the benefits of Daily Scrum?

Improve communications
Reduces the need for other meetings
Identify impediments to development for removal
Highlight challenges
Promote quick decision-making,
Improve the level of knowledge
Moreover, it is an Inspect and adapt meeting.

The Product Owner will take a call if the work done is valuable for the product.
- If yes, it is accepted, and the remaining part will be re-estimated and moved back to the Product Backlog.
- If no, the remaining effort for the story will be re-estimated and moved back to the Product Backlog.
This incident will be considered during review and/or retrospective as an inspect and adapt opportunity.

Can a Scrum Master direct a team member on how to do a task?

Agile is focused on self-organizing teams.
It is not a command-Control environment.
The team organizes and decides how to manage their work to achieve the goals.
Scrum Master is not assigning tasks to the team.
But with their expertise, from the capacity of a team member, Scrum Master can contribute.

Which is the longest event Scrum, there are four other events,

We can consider the Sprint itself as the longest event in Scrum.
Sprints contain and consist of Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. Sprint is time-boxed to one month or less.
- 1. Sprint Planning: This event is time-boxed to a maximum of 8 hours for a one-month Sprint. For shorter Sprints, the duration is usually shorter.
- 2. Daily Scrum: This event is time-boxed to 15 minutes each day.
- 3. Sprint Review: This event is time-boxed to a maximum of 4 hours for a one-month Sprint.
- 4. Sprint Retrospective: This event is time-boxed to a maximum of 3 hours for a one-month Sprint.
Given these durations, the Sprint Planning event is actually the longest event in Scrum, not the Sprint Retrospective. For a one-month Sprint, Sprint Planning can take up to 8 hours, whereas the Sprint Retrospective can take up to 3 hours.

What are the common features of Scrum events?

All events are time-boxed, and every event has a maximum duration.
Once a Sprint begins, its maximum duration is fixed.
Each event in Scrum is a formal opportunity to inspect and adapt.
These events enable transparency and inspection. Exclusion of any of these events will have an impact on transparency and reduce the opportunity to inspect and adapt.
There is no gap between Sprints. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprint Goal is finalized during Sprint Planning.
During the Sprint, no changes are allowed that would endanger the Sprint Goal.
The scope may be clarified and re-negotiated between the Product Owner and Developers as more is learned.

Can we cancel a Sprint?

A Sprint can be canceled before the Sprint time-box is over.
It is a decision from the Product Owner.
Only the Product Owner has the authority to cancel the Sprint.
A Sprint will be canceled if the Sprint Goal becomes obsolete.

What is Sprint Review?

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.
This meeting concentrates on the outcome of the Sprint.

What is the intent of Sprint Review?

This Discuss what was done in the Sprint and What are the next things that could be done to optimize value. This is an informal meeting. This is not a status meeting.
The Scrum team will present the Increment to the participants.
The Increment is presented to elicit feedback and foster collaboration.
The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”.
The Scrum Team demonstrates the work that it has “Done” and answers questions about the Increment.
The Product Owner discusses the Product Backlog as it stands and projects likely completion dates.
The entire group collaborates on what to do next.
The result of the Sprint Review is a revised Product Backlog.
The Product Backlog may be adjusted to meet new opportunities.

Who all are the participants in Sprint Review?

Attendees include the Scrum Team and stakeholders invited.

What is the duration of Sprint Review?

This is a four-hour time-boxed meeting for one-month Sprints.
For shorter Sprints, it will be shorter. In other words, it is time -boxed to 4 hours.

Sprint Retrospective

What is Sprint Retrospective? What are the benefits of Sprint Retrospective? When should we conduct a Sprint Retrospective?

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
The Sprint Retrospective concludes the Sprint.
Action items coming out of retrospective will have an impact on the next planning.
This is a three-hour time-boxed meeting for one-month Sprints.
This meeting Inspects how the last Sprint went with regards to people, relationships, process, and tools and identify the major items that went well and potential improvements.

How will you do Sprint Retrospective? Explain the method used.

Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
There are different techniques used for conducting Sprint Retrospectives.
A widely used method uses three categories to give a structure for the discussions,
- What went well,
- What didn’t go well,
- What are the points to improve?
The team discusses these points and comes out with an action plan.
Instead of attacking all items, the Scrum Team identifies the most helpful changes to improve its effectiveness.
The most impactful improvements are addressed as soon as possible.
They may even be added to the Sprint Backlog for the next Sprint.

What is Scrum of Scrums? What are the benefits of Scrum of Scrums? Who all are the participants in Scrum of Scrums?

A Scrum of Scrums is an event for enhancing coordination among Scrum teams when many teams are working for the same product.
This is not a defined event.
Frequency and time-box are fixed at the beginning of the project.
Scrum Master or representatives from all teams participate.
A few points discussed in the meeting are:
- Progress of the team, after the last meeting,
- The task to be done before the next meeting,
- Impediments which the team is facing.
The focus will be on cross -team dependencies and common issues.

Can we have Sprint Review during the next Sprint?

Sprint Review must be conducted before the next Sprint Planning.
The decision during the Sprint Review may make changes in the Product Backlog and influence the next planning.
As every event is important for the success of Scrum and is immutable, the sequence of the events is also equally important.
We should maintain a proper sequence.

What should we do if we are not able to finish Sprint Goal?

The Product Owner will take a call if the work done is valuable for the product.
If yes, it is accepted, and the remaining stories will be re-estimated and move back to the Product Backlog.
This event will be considered during review or retrospective as an inspect and adapt opportunity.
The team should maintain high levels of transparency.
The moment they understand the goal is not achievable, they should discuss the same with the Product Owner.
Probably they can renegotiate the scope.

Can we change requirements within the Sprint?

In Scrum, Sprint Goal remains unchanged within the Sprint.
But there may be unforeseen situations where there are changes that impact the scope.
The team should discuss with the Product Owner and discuss the impact of the changes.
Sprint Goal should not get impacted by such changes.
At times we have to re-negotiate the scope to accommodate the changes.
If the Product Owner is agreed to the impact and if the team feels these changes are within their capacity, these changes can be welcomed without endangering the Sprint Goal.

What Is Timeboxing?

Timeboxing makes sure that an event takes not more than the recommended duration.
In Scrum, all prescribed events are time -boxed.
This keeps the participants focused on the task and avoids unnecessary discussions.

What is the duration of a Sprint?

Sprint length can be one month or less.
This is decided based on the nature of the project and delivery requirements.
A few points to consider are –
- Should be of one month or less,
- How long we can keep selected requirements unchanged,
- The time required to create an Increment, shorter duration is preferred.

What are the advantages of maintaining consistent iteration length throughout the project?

Consistent Sprint length helps the team to objectively measure progress.
It provides a consistent means of measuring team velocity.
Equally sized iterations help to establish a consistent pattern of delivery.
It brings in better cadence and makes events more predictable.

What is the difference between Sprint Review and retrospectives?

Sprint Review focuses on:
- The product
- The Increment and
- The current state of the Product Backlog.
Sprint Retrospective focuses on:
- How it is made.
- It Inspects how the last Sprint went with regards to people, relationships, processes, and tools.

SCRUM ROLES

What are the different SCRUM Roles?

The roles defined by Scrum are the Product Owner, Developers, and the Scrum Master.

Role and Responsibility of a Product Owner

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
The Product Owner represents the business and is responsible for the requirements.
He is the single source of requirements for the Developers.
The Product Owner owns the Product Backlog.
He or She creates and maintains it.
The Product Owner gives the business direction for the team.

Responsibilities of a Product Owner:

Owns the requirements that are the Product Backlog,
Defines the features of the product,
Is Responsible for the content,
Be responsible for the profitability of the product,
Prioritizes features according to market value, adjusts features, and priority every iteration, or as needed.
The Product Owner is accountable for effective Product Backlog management, which includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and
- Ensuring that the Product Backlog is transparent, visible, and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

Role and Responsibility of a Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment for each Sprint.
They are a self-organizing, cross-functional team doing the work towards the Sprint Goal.
They are expected to have all the skills to convert the selected backlog items to a tested, ready -to -ship Increment.
Members should be full-time, maybe with minor exceptions.

Role and Responsibility of a SCRUM Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness.
They do this by enabling the Scrum Team to improve its practices within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
The Scrum Master is responsible for ensuring Scrum is understood and enacted.
Scrum Master is a true leader for the team.
He/she facilitates the Scrum events and makes sure the impediments are handled.
Scrum Master responsibilities include,
- The Scrum Master is a true-leader for the Scrum Team
- Removing impediments to the team’s progress
- Enable close cooperation across all roles and functions
- Shield the team from external interferences
- Facilitating Scrum events as requested or needed
- Coaching the Development Team in self-organization and cross-functionality.

What is the level of interaction Product Owners have with delivery teams?

As per agile principles, businesses and Developers should work together on a daily basis.
Here the Product Owner represents the business.
The Product Owner should be available for the team throughout the project.
Scrum prescribes events and artifacts to enhance and support these interactions.
But we should not limit ourselves only to these events.
There should be interactions on a daily basis.

What is an ideal team size?

Scrum Guide says: “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically ten or fewer people”.
Less may result in skill constraints, and having more may result in too much coordination effort, complexity.

What are component teams and feature teams?

Component teams are considered to be made up of experts in a specific domain, and they are focused only on the work related to their domain. For example, there will be teams for User Interface, Database, Business Logic, etc.
Feature Teams are cross-component, cross-functional teams working on the specific behavior of the system. It will have the expertise to work on all the components required for that feature.

Does Scrum Master remove impediments on behalf of the Scrum team?

Handling impediments and making sure that they are not creating blockers is one of Scrum Master’s responsibilities.
It is a collective responsibility of the self-organizing team.
Scrum Master should track and facilitate this process.

You have conflicting requirements from two different stakeholders on a common scenario; how would you handle this?

We should address it to the Product Owner.
The Product Owner owns the requirements, and they have the final decision.
Product Owner is the single source for requirements for the development team.
Whoever wants to add features to the product should address it to the Product Owner.

Why should the Developers be cross-functional?

The aim of any Sprint is to produce a shippable product Increment at the end.
The Scrum Team manages their work towards producing a shippable product Increment at the end of every Sprint.
This work needs expertise across different domains.
The team should have all, at least most of the capabilities required to produce this Increment.

Do we have a Project Manager role in Scrum?

There is no Project Manager role defined in Scrum.
Scrum depends on self-organizing teams, and they manage themselves.
Project Management roles may exist at other levels in the organization.
They should work towards empowering and supporting Scrum teams.
Support from management is very important in the success of Scrum.

Who should conduct Scrum ceremonies in the absence of a Scrum Master?

The Scrum Team is self-organizing and self-managing.
Scrum Master coaches the team in self-organizing.
It is the team that conducts the ceremonies.

Do you think a Scrum Master should be a technical person?

The Scrum Master does not necessarily have to be a technical person.
But technical knowledge will help Scrum Master.
In many teams, Scrum Master may take up the additional role of a development team member if he/she has the expertise and bandwidth.

AGILE MONITORING

What are the basic features of Agile Metrics?

We should go for only the Minimum number of metrics that will provide all information necessary to meet business goals.
We should not measure just for the sake of doing it. There should be a value, a benefit from it.
Metrics should measure outcomes, not outputs. They must measure results, not activity.
Agile focuses on the value created. So, the focus will be on Measuring work items completed, not time spent on it.
Metrics should assess the trends, not snapshots.
They should provide feedback at frequent and regular intervals.
And metrics should be easy to collect.

What is velocity?

Velocity indicates the past performance of the team.
Expressed as the total number of Story points completed in an iteration.
Velocity is Sum of Story points completed in an iteration.
Only points from completed stories or features are counted.
It helps during planning. It serves as an indicator of the size of work the team can take.
We should not compare the velocity of different project teams;
we can compare across iterations for a given team.
The velocities of a team across iterations can be plotted in a velocity chart.
It helps in analyzing the trends within the team across iterations.

What is Sprint burn-down chart? Who updates the Sprint burn-down chart?

A Sprint burn-down chart shows the total identified work remaining in an iteration.
It has Days as X-axis and the remaining identified effort from Sprint Backlog as Y-Axis. Sprint
Burn Down chart tracks the ongoing iteration.
Developers update Sprint Backlog with remaining effort for all ongoing tasks.
Sprint Backlog is a live document.
A new task can be added at any time during the Sprint.
So, there can be a temporary burn-up in the burn-down chart.

What is the release burn-down chart?

We should always remember that we have a high-level plan at the release level.
This is based on what is known at the time of creating this plan.
This may change as more knowledge is available.
A burn-down chart can be used at the release level to track the number of story points remaining to be done in the release.
The vertical axis shows the number of story points remaining in the release, and Iterations are shown across the horizontal axis.
It shows the amount of work remaining at the start of each iteration.
It may show a burn-up because work has been added; that is, a new backlog item has been added to the release.
The scrum team makes sure that this is updated at the end of each Sprint.

What is the release burn-up chart?

Again, the number of story points is tracked here. But in a burn-up chart, we track the number of points done, not remaining.
The vertical axis shows the number of story points done so far in the release.
Iterations are shown across the horizontal axis.
It shows the amount of work that is story points completed so far at each iteration.
The reference line, as given in blue color in the figure, shows the total size of the Product Backlog and can go up if new stories are added or estimation changes.

What is an Impediment? How do you track impediments?

An impediment is anything that reduces the chances of achieving the Sprint Goal.
It can also be defined as anything that creates a blocker in the Sprint work.
These should be identified, tracked, and resolved.
A good practice team should discuss this as part of Daily Scrum.
Each team decides their metrics based on what they want to measure and why.
Metrics should help the Scrum Team in delivering as a self-managed unit and should not become an impediment on their way.

Quick overview of other agile methodologies

What is the Kanban approach in software development?
- Kanban is a lean approach to agile software development.
- Kanban is for managing the creation of products, with an emphasis on continual delivery while not overburdening the development team.
- Each work item will pass through a series of process steps or workflow stages before it is done.
What are the core practices of Kanban?
- Visualize the flow
- Limit work in progress
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively, and
- Evolve experimentally.

What are WIP limits?
- WIP limits or work in progress limits is the maximum number of work items that can be in a particular stage of processing. This will avoid the overloading of the production chain.
- One of the main benefits of Kanban is to establish an upper limit to the work – in – progress inventory, avoiding overloading of the manufacturing system.
History of KANBAN:
- Kanban means signboard or signal – initially developed as a scheduling system that is used in manufacturing
- In 1940s, Toyota came up with a Kanban system to implement a Just-in-time process to standardize the flow of parts in their production lines.
What are Kanban principles?
- The principles are,
  - start with the existing process,
  - agree to pursue Incremental and evolutionary change.
  - Respect the current process roles, responsibilities and titles, and Leadership at all levels.

Explain Cycle time, Lead time, Response time, and throughput.

Lead time

Lead time is the period between a new task that appears in your workflow and its final departure from the system.
This can be considered as the lifetime for an item in the system.

Cycle time

Cycle time begins at the moment when the new arrival enters the “in progress” stage, and somebody is actually working on it till it finishes.
This will show the processing time took for an item.

Response time

Response time is the period between when a new task appears in your workflow and enters the “in progress” stage.
This shows how much time an item had waited in the system before the work started on it.

Throughput

Throughput is the number of work items delivered in a given period of time.
It shows the number of items processed by the system.

What are the differences between Scrum and Kanban?

In Scrum, we follow Regular fixed length Sprints of maximum 1month duration.
In Kanban, it is a continuous flow.

In Scrum, we release at the end of each Sprint if approved by the Product Owner or as decided based on different factors;
Kanban is a Continuous delivery.

Scrum defines roles Product Owner, Scrum Master, and Developers.
There are no Kanban -specific roles defined.

Scrum teams use velocity to measure the amount of work done by the team in a Sprint.
In Kanban, key metrics are cycle time, throughput, etc.

In Scrum, Sprint Goal is decided during the Sprint Planning, whereas
Kanban uses a pull system.

In Scrum, no change to the Sprint Goal is recommended within the Sprint, but
Kanban accommodates changes with more flexibility.

What is Scrumban?

Scrumban is a hybrid of Scrum and Kanban.
It uses the prescriptive nature of Scrum and the process improvement of Kanban.
It meets the needs of teams wanting to minimize the batch size of work and adopt a pull-based system.

What are different Roles in Extreme programming?

What are XP Values?

Extreme programming is intended to improve software quality and responsiveness to changing customer requirements.
XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.
Extreme programming has core values of Communication:

Simplicity,
Feedback,
Courage, and
Respect.
Different roles defined in XP are

XP Coach,
Customer,
Programmer,
Tracker, and
Tester.

What are the practices of Extreme Programming?

Practices of Extreme Programming are:
Planning Game
Test Driven Development,
On-Site Customer
Pair Programming
Continuous Integration
Refactoring
Small Releases
Simple Design
Collective Code Ownership
System Metaphor
Coding Standards, and
Sustainable pace.