1.What is Agile Software Engineering, and what are its core principles?

Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference for the shorter timescale.
Business people and developers must work together daily throughout the
project.
Build projects around motivated individuals.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
The best architectures, requirements, and designs emerge from self-organizing
teams.
At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behaviour accordingly.
4. Describe the Agile Manifesto and its values. How do these values
guide Agile development practices?
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

The Agile Manifesto is a set of guiding principles for software development,

emphasizing flexibility, collaboration, customer satisfaction, and iterative
development. It was created in 2001 by a group of software developers who were
seeking a more adaptive and responsive approach to software development
compared to traditional, plan-driven methodologies.

The Agile Manifesto values are as follows:

Individuals and Interactions over Processes and Tools: Agile emphasizes the
importance of people working together effectively and communicating directly,
rather than relying solely on rigid processes and tools. This value promotes
teamwork, collaboration, and the ability to adapt to change.

Working Software over Comprehensive Documentation: Agile prioritizes

delivering functional software over extensive documentation. While
documentation is important, Agile encourages focusing on creating working
software that meets the customer's needs and can be tested and improved upon
iteratively.

Customer Collaboration over Contract Negotiation: Agile emphasizes involving

the customer or stakeholders throughout the development process, seeking their
input and feedback regularly. This collaborative approach helps ensure that the
product meets the customer's requirements and expectations.

Responding to Change over Following a Plan: Agile recognizes that change is

inevitable in software development and values the ability to respond to change
quickly and effectively. Instead of rigidly following a predefined plan, Agile teams
adapt and adjust their plans based on feedback, new information, and changing
priorities.
5. What is a Sprint in Agile, and what activities typically occur during
a Sprint?
 Sprint
 At the core of Scrum – represents each iteration
 Starts with a Sprint Planning Session where a set of features are
taken from Product Backlog to form Sprint Backlog
 During the Sprint, meetings are held daily to review progress
 During the Sprint, a set of useful functionality is developed
 Actual release to customer may occur after one or a few sprints
depending on the value it adds for the customer
 At the end, a Sprint Review is held to assess performance and
change for the better

Extreme programming
 Focus is:
 customer satisfaction
 by developing software features
 when the customer needs them
 Planning is done by whole team – no disconnect between business and
developers
 Co-location of developers and business users
 Coding is core activity – coding standards are encouraged and collective
code ownership are encouraged
 Simple stories and metaphors are used to provide easy understanding
 Sustainable pace is maintained – working week of 40 hours
 Pair programming – two people working on one task (driver + navigator)
 Overall design is considered during refactoring i.e. process to
systematically improve code to improve readability, reduce complexity,
improve maintainability
 Intensive testing – coding only done after tests are designed and
developed – automated testing within the codes recommended
 Continuous integration and small releases promoted
 Direct communication between customer and programmer
Sprint
 Sprint - consistent iteration of time to create a group of product features
 Long sprints run the risk of having priorities change during the sprint
 Each sprint consists of:
 Sprint planning
 Daily scrum planning
 Development time
 Sprint review
 Sprint retrospective

Sprint planning
 Establish goals for the sprint
 Choose user stories that support these goals – if necessary create new
user stories
 Create sprint backlog
 User stories in order of priority
 Effort estimate, value and risk
 Tasks needed for each story
 Effort for each task (hours – less than a day)
 Work on one sprint at a time – do not bother about future sprints
 Whole team works on one user story at a time until completion- swarming
 If all work does not fit the sprint, remove some user stories (time is fixed)
Sprint review - What it is
 The aim is to :
 Demonstrate and review functionality created by the development
team on the basis of the user stories in the sprint backlog and
completed during the sprint
 Collect feedback and update the product accordingly
 Attended by the product owner, development team, scrum master (if
needed) and any stakeholders
  Should not last more than 1 hour for a 1 week sprint

6. How do you estimate and plan work in Agile? What techniques or

tools can be used for estimation?
Establishing & Arranging product features
 Hierarchy of requirements
 Themes: Logical groups of features at their highest levels
 Features : Parts of the product which give a new capability to the
customer
 Epic user stories: Medium-sized requirements decomposed from a
feature and often contain multiple actions or channel of value
 User stories: Requirements that contain a single action or
integration and small enough to start implementation into
functionality
 Tasks: Steps/actions that need to be taken to develop a requirement
into working functionality
 No need to have all the levels – use on a need-to basis
Estimating development effort
 There are different ways to estimate effort:
 Historical approaches
 Analogous estimates
 Lines of code
 Function points
 Object points
 Duration = Adjusted Effort / Average productivity
 The problem with traditional effort estimating is that they look accurate
when in fact they are not
 Agile estimating uses relative estimating with story points:
 Extra small: 1 point
 Small: 2 points
 Medium: 3 points
 Large: 5 points
 Extra Large: 8 points
  Team agrees on what features correspond to the above sizes
 Relative estimates follow the Fibbonacci sequence

Estimating business value & risk

 Evaluate the value of each requirement:
 Qualitative: low, medium, high as evaluated by stakeholder
 Narrative: sentence to explain the perceived value added
 ROI: economic benefits of the feature
 Evaluate the risk:
 Risk relates to the negative effect on the project if the specific
feature failed
 Qualitative: low, medium, high
 Monetary value of failure
 Prioritise according to value and risk
 High value and high risk get priority
 High value improve customer satisfaction
 High risk favour early and cheap failure to rear-loading of risk
 Result is the first version of product backlog

Estimation poker
 Provide each team member with estimation poker cards
 Team agrees on one story whose complexity is 5 story points (large) –
known as the anchor story
 Team takes a high priority story
 All members simultaneously show their estimate by turning their card
 If estimates are different, discuss, review assumptions and repeat the
estimation exercise – if no consensus is reached, help of scrum master is
sought
 Estimation repeated for all user stories
 When there are too many stories, group them per category and estimate
the effort for the category (affinity estimating)
 Use food, humour, breaks to make estimation poker enjoyable
Other estimation techniques
 T-shirt size estimation
 Use size of T-shirts to estimate effort behind development
 Group user stories of same sizes together
 Start with an agreement on a M size user story
 Other stories are then classified into XS, S, M, L and XL
 Bucket estimating
 Arrange a series of buckets of sizes 1, 2, 3, 4,5, 8, 13, 20, 50, 100,
200
 Select a story at random and place it in 8
 Discuss the story and its assumptions to understand the effort
 Take another story and place relatively
 Do the same with other stories
 In case, the first story needs to be re-assigned, do it
 Overall sanity check
 Important for consensus during estimation
8. How does Agile handle changing requirements during the
development process?
Iterative Development: Agile projects are divided into short iterations or sprints,
typically lasting one to four weeks. At the end of each iteration, a potentially
shippable product increment is delivered. This allows for frequent opportunities
to review and adjust requirements based on feedback from stakeholders and
changes in the business environment.

Continuous Feedback: Agile encourages regular feedback loops with

stakeholders, including customers, end-users, product owners, and other
relevant parties. By obtaining feedback early and often, Agile teams can quickly
identify changes in requirements and adjust their plans accordingly.

Adaptive Planning: Agile embraces the idea that plans are subject to change and
uncertainty. Instead of creating detailed, rigid plans upfront, Agile teams engage
in adaptive planning, where plans are continuously refined and adjusted based
on evolving requirements and priorities.

Prioritization: Agile teams work closely with stakeholders to prioritize

requirements based on their value and importance to the business. This allows
teams to focus on delivering the most valuable features first, while remaining
flexible to accommodate changes in priorities.

Collaboration and Communication: Agile promotes collaboration and open

communication among team members and stakeholders. When requirements
change, Agile teams engage in discussions to understand the implications and
make necessary adjustments to the project scope, timeline, and resources.

Incremental Delivery: Agile encourages delivering working software

incrementally and frequently. By breaking down the project into smaller,
manageable increments, teams can respond more effectively to changing
requirements and deliver value to stakeholders sooner.

Refactoring and Continuous Improvement: Agile teams continuously refactor

code and processes to maintain flexibility and adaptability. Refactoring involves
restructuring code or design to improve its maintainability and extensibility,
making it easier to accommodate changes in requirements without introducing
unnecessary complexity.

9. What is a retrospective meeting in Agile, and why is it valuable for the

team?

Sprint retrospective
 It is a meeting in which product owner, development team and scrum
master discuss:
 How the sprint went (good and bad)
 What they can do to improve the next sprint
 Similarity with sprint review: both are done at the end of a sprint
 Difference with sprint review: sprint review is a demo of work done
whereas sprint retrospective is a discussion on how to improve things
 Meeting should be as self-directed as possible i.e. not supervisors
interfering to allow everyone to be open with each other
 If necessary, other stakeholders may be invited (especially if they are part
of a problematic part)
 Benefit of improving process is to improve team velocity, efficiency and
team morale
 No one size fits all – each team has its own unique dynamics
 Scrum processes will expose problems but will not solve them – the team
should use the sprint retrospective to find solutions

The sprint retrospective meeting

 Other areas for discussion:
 Results : work completed v/s work planned, check sprint burndown
chart
 People: team composition
 Relationships: communication/collaboration with peer and other
stakeholders
 Processes: check design, development, review and testing
processes
  Tools: how are the chosen technologies and tools working for the
team – any hick-ups, wrong choices or skill gaps to be highlighted
 Productivity: is the team’s productivity as expected and whether it
required any improvement

The sprint retrospective meeting

 Proposed modus operandi:
 Set the stage: remind the goals of the meeting
 Gather data: record feedback and try to paint the big picture – a
white board / sticky notes can help. It can be helpful to review
actions taken in last retrospective and see if they worked.
 Generate insights: get ideas for further improvements
 Decide what to do: evaluate ideas and prioritise actions to be taken
 Close the retrospective