Understanding Agile

Four Values of agile

2
Twelve Principles of Agile

3
What is Agile ?

4
Many Approaches to Agile

5
The Value of Agile Principles and Practices

Organizations who use agile principles and practices have documented the
value they see from the philosophy and techniques:
➢ Adaptive to changing business needs, giving the organization more
influence over adding, changing, or removing requirements
➢ Early and continuous customer feedback improves communication and
empowers business owners who can receive and review critical
information necessary to make decisions to steer the project throughout
the development process
➢ Early measurable return on investment
➢ High visibility and influence over the project progress leading to early
indications of problems
➢ Incremental delivery rather than a single complete delivery at the end
of the project; reduces product and process waste

6
Examples of Agile Principles and Practices

The following examples help illustrate the application of agile principles and
practices:
Early, measurable return on investment through defined, iterative delivery of
product increments
➢ High visibility of project progress, allows early identification and
resolution or monitoring of problems
➢ Continuous involvement of the customer through the product
development cycle
➢ Empowerment of the business owner to make decisions needed to
meet goals
➢ Adaptation to changing business needs, giving more influence over
requirement changes
➢ Reduced product and process waste

7
The new age of knowledge workers

Industrial Workers Knowledge Workers

Work is visible Work is invisible
Work is stable Work is changing
Emphasis is on running things Emphasis is on changing things
More structure with fewer decisions Less structure with more decisions
Focus on the right answers Focus on the right questions
Define the task Understand the task
Command and Control Give autonomy
Strict Standards Continuous Innovation
Focus on Quantity Focus on Quality
Measure performance to strict Continuously learn and teach
standards
Minimize cost of workers for a task Treat workers as assets, not as
costs

8
Value Based Delivery

9
Development Approach

10
Waterfall v/s Agile project management

11
Agile Project Management

12
Scrum Roles, Artifacts and Ceremonies

13
Planning Scope
Agile Scope Management

➢ In Projects with evolving requirements, high risk or significant uncertainty , the scope is
not often understood in the beginning of the project or it evolves during the project.

➢ Agile methods deliberately spend less time trying to define and agree on scope in the
early stage of the project and spend more time establishing the process for its ongoing
discovery and refinement.

➢ Many environments with emerging requirements find that there is often a gap between
the real business requirements and the business requirements that were originally
stated.

➢ Therefore agile methods purposefully build and review prototypes and release versions
in order to refine the requirements.

➢ As a result, scope is defined and redefined throughout the project.

➢ In agile projects , the requirements constitute the Product Backlog 15
Kano Analysis Model

16
Balancing Risk and Value

17
Product Backlog

➢ The product backlog is one of the key list of items that are yet to be
implemented by the development team.

➢ It can contain business requirements expressed as epics, features or

stories, defects, risks, or technical tasks identified by the team.

➢ It is not necessary that all items in the product backlog will be

implemented or necessary for shipping a working version of the
product.

➢ Only the ones that yield value (or mitigates risks) are prioritized and
delivered in the same priority order by the team.

➢ Some items from the backlog could even be simply discarded (so they
never get implemented) based on very low priorities assigned to them.
18
Prioritized

19
DEEP Attributes of Product Backlog

20
Risk Adjusted Backlog

➢ The discussions around product backlog are not complete without considering
risks, which is a very realistic aspect of project management.

➢ In simple terms, once risks are identified, they are analyzed for their impact,
probability and frequency.

➢ Finally, appropriate responses are sought to mitigate them. These risk

response strategies are then combined to the existing product backlog along
with the functional requirements.

➢ This combined list containing the functional requirements as well as the risk
responses in order of priority is called a risk adjusted backlog.

➢ This gives the product owner and the development team one list to refer during
planning and prioritization such that a balance is maintained between meeting
functional requirements and mitigating risks.

21
Backlog Grooming or Refinement

The Product Owner, as in the case of Scrum, continuously updates the backlog in
response to one or more of the following events in the project environment:
❖ A new requirement emerges during review of the product at the sprint review meeting.

❖ A regulatory constraint was imposed.

❖ There are economic conditions at the market place (a share price for a commodity or a
foreign exchange rate has changed) that might affect the business value of product.
Consequently features could either be added, or deleted as a result of the same.

❖ A new customer segment has been discovered (or who have expressed desire to use
the product).

❖ Dependencies with other internal products (in the same organization) or external
interfaces (outside the organization boundary) are discovered.

❖ The team identifies a risk that needs to be mitigated.

❖ The product should seize competitive advantage because of similar offerings available
from competitors.
22
❖ There are technical considerations that impact the architecture and design.
Minimally Marketable Features (MMF)

23
Adaptive Planning

24
Release Planning

The release plan is generally outlined by the product owner. He uses the
release plan to provide visibility to all stakeholders by giving them what to
be expected when. At a high level the product owner could base the
release plan on a few circumstances prevailing in the project and its
environment, like:
➢ Regulatory constraints that the product and the organization needs to comply with,

➢ Gaining competitive advantage in the market place,

➢ Contractual obligations to meet a particular milestone,

➢ Passing on benefits to the customer,

➢ Exploiting opportunities to test incremental versions of the product (e.g., beta testing of
some features),

➢ Avoid losses or penalties for not delivering a predetermined scope at a particular time.

25
Levels of Planning - The Planning Onion

26
Product Roadmap

27
Release Plan
➢ Let us take a close look at Figure 6-26 below that depicts a sample release plan. Conceptually a
project can comprise of one or more releases (three in this case) and each release can have
multiple iterations28 (the number could vary for every release). The project starts off with a Sprint
zero where most of the setup is done and before every release there is a hardening sprint where the
software stability is ensured before being released to production. Every release ends with a review
of the working software and a retrospective. It is also to be remembered that during iteration
planning, the team maintains a close vigil on the overarching release plan and see that all items
required in the release are completed during the iterations that go into a release.

28
Hierarchy of Epics, Features, Themes and User
stories

29
Decomposing Project Requirements

➢ Breakdown of the project work

➢ Epics –large user stories that span one or more iterations

➢ Feature –attributes of the product

➢ User story –decomposition of a feature

➢ Task –smallest element of the decomposition

30
Creating A User Story

➢ Potential stories are called candidate stories

➢ Perspective of the user or customer

➢ Often written in the following format

➢ As a role I want functionality so that business benefit

❖ Answers two questions:

❖ Who was asking for this?

❖ Why are we doing this?

31
Three C’s Of User Stories

32
Attributes of User Stories/Tasks

33
Units of Estimation: T-shirt Sizes

34
35
Creating Agile Estimates

➢ Factoring Ideal Time

❖ Estimate as if there would be no
interruptions

❖ Ideal time assumes all time in the

estimate is for project work

➢ Assumptions for Sizing & Estimating

❖ Details emerged as the project moves
forward

❖ Plans are adjusted based on feedback

❖ Privatization happens throughout the

project

37
Relation between Product Backlog & Sprint
backlog

38
Computation of Velocity

39
Release burndown charts

40
Manage Knowledge
Retrospectives

Retrospectives, also sometimes referred as reflection workshops, are

forums for Agile teams to look back, reflect and evaluate the
performance of their processes at the end of each iteration. In Agile
methods like Kanban where there are no iterations, teams could be
running retrospectives at predefined intervals like once in 2 weeks or
so, timeboxing it to an hour or two.

42
Comparisons between lessons learned and
retrospectives

43
Styles of retrospectives

➢ SAMOLO - Same as – more of – less of

➢ Start doing – stop doing – keep doing

44
Steps of a retrospective

45