2. P K Mallik
• Objectives
• Benefits
• Key Concepts
• Estimation
• Prioritization
• Releases and Iterations
• Framework
• Planning
• Tracking
• Guidelines
Agile Framework
3. P K Mallik
Objectives
• Create clear business value across stakeholders
• Improve predictability of project and product delivery
• Create environment where deviations are the exception
4. P K Mallik
Key Benefits
Resourcing
• Faster skill
development
through craft model
• Specialists used on
need basis leads to
greater availability
• Devolution of
responsibilities
ensures ease of
acquisition
• Shorter planning
window ensures
resources are not
tied up
• Training to be co-
ordinated with CoE
Lower Costs
• Improved resource
mix (larger
proportion of low
cost resources)
• Tactical usage of
high cost resources
in iterations
• Clear productivity
measures to monitor
and improve
productivity
• Reduced idle time
from need based
allocation of
resources to
iterations
Value Delivery
• Prioritise by Business
Value
• Greater flexibility in
defining requirements
• Flexibility in
scheduling high risk
items to reduce risks
• Continuous build
ensures lower defects
• Early feedback gives
opportunity to add
details to user stories
in downstream
iterations
• Iterations focus on
subset of scope to
reduce errors in
requirement
definition
5. P K Mallik
Stakeholder Benefits
Sales
• Lower Prices from improved resource mix with lower percentage of expensive
resources
• Better Business Value to customer from delivery prioritisation based on value
generated
• Quicker Deliveries using iterative approach with short durations
• Quicker realisation of additional business opportunities through early demonstration od
capabilities
Delivery
• Greater control from shorter iteration durations leads to higher predictability
• Impact of changes limited to current iteration only prevents cascading delays and schedule
disruptions
• Focus on a small segment of requirements in each iteration ensures greater clarity on
requirements at the time they are being developed
• Increases probability of detecting defects before UAT through greater focus on a small segment of
features
• Efficient utilisation of specialist resources leads to lower cost to project
• Clear productivity measure in Story Points makes if possible to identify and implement productivity
improvements
Services
• Greater flexibility in resourcing enables quick response to customer needs
• Delivery costs reduced through lower cost resources assuming greater responsibility
• Shorter planning cycles allows for variable team sizes and less overtime discount (extra
hours worked for free)
• Get a larger part of business through higher productivity in multi vendor scenarios
Customer
• Business Value
Priority
• Continuous
Engagement
• Lower Costs
• Greater
predictability
• Greater flexibility
in requirement
• Lower Defects
• Shorter
realisation time
• Lower risks
6. P K Mallik
Key Concepts
Term Description Example
Epic A very large user story, needs to be split into
smaller stories to fit the iterations
Member searches for products and adds one or
more to a shopping cart
Theme A grouping of User Stories usually based on
functional area or module
Security consisting of Login, Change Password,
Access Control
User Story A high level requirement presented in one or
two paragraphs of text
Members will register by providing their contact
information and email address
Story Points Number associated with a user story to indicate
relative complexity. Must be consistent within a
project across teams
Member Login 4 story points
Member registration 14 story points
Purchase goods and services 43 story points
Release A group of user stories that will be delivered as
a system or enhancement in a given period
Member Login, Member Registration, Select
Products, Check Out and Pay
Sprint or Iteration A short term plan (typically 2 to 4 weeks)
identifying which user stories will be completed
in that time frame
Iteration 1 : Member Login UI, password
verification, master form, menu access
Iteration 2 : Member Registration Contact
Details
Iteration 3 : Member Registration send password
by e-mail
Task Detailed requirements that describes
functionality and features of a user story
The email id provided must be unique for the
member and must be a valid e-mail id.
The member password will be sent to the e-mail
is provided by the member and must be changed
on login
Velocity The number of story points that would be
completed in an Iteration (Sprint)
Iteration 1 : Member Login (4 Story Points) +
Default Form (10 Story Points) = Velocity of 14
7. P K Mallik
3 story points
5 story points
8 story points
Agile Estimation – Story Points
• Story points measure the relative size of a story,
theme or epic
• Since story points are relative, the estimates do
not change over time, for example increase in
familiarity with the technology will increase
productivity, but this is uniform so relative sizes
remain the same
• Story points can be estimated by analogy, a
process which is more accurate than trying an
absolute estimate
• Story point estimation is faster as it only requires
a high level design discussion
• To estimate story points a base requirement (user
story) must be defined, all other requirements
will be measured relative to the base requirement
User
Story 1
User
Story 2
User
Story 4
User
Story 3
User
Story 4
User
Story 4
New User
Story
Analogy
Story complexity indicated by box size
Story Points measure the complexity of the requirement and not the complexity of delivery. Complexity of delivery is measured in
Velocity (story points per iteration) and iteration length.
8. P K Mallik
Estimating Story Points
• For projects
– Define a login form (User Id, Password, Remember Me, Forgot Password) as a base
requirement with 12 Story Points
– All other requirements to be measured relative to this base
– Estimation metrics to define activity effort based on story points
• For Product Implementation
– Story points to be defined for product features
– Story points to be defined for Installation, configuration and demonstration for
each feature
– Customization to be estimated similar to projects
– Base feature to be selected for comparison to estimate other features
– Base feature story points to be assigned by comparison to project base requirement
(user login)
• Size is determined by activities necessary to meet the requirement.
Factors affecting size are
– Complexity of the requirement
– Need for extra testing
– Interface with external systems
– Performance criteria specified for the requirement
This excludes high level requirements, architecture and high level design activities which need to be estimated separately
9. P K Mallik
Agile Estimation – Staffing
• Number of Iterations = Total Story Points/Velocity based on platform
• Team size = ((Iteration Length * Number of iterations) + Schedule Buffer) /
Scheduled duration)
• Typical iteration length should be 2 weeks
• Iteration length can be 3 weeks at start-up
• Teams of over 10 members should be split up into 2 or more teams
• Roles to be determined based on effort by activity
• Activities which are calendar based, such as overarching activities
(project management) or time bound activities (support) should be
estimated on a T&M basis
• Where team size is fixed, available story points will determine which user
stories can be taken up where:
– Number of Iterations = (Target Duration – Schedule Buffer) /Iteration Length
– Available Story Points = Number Of iterations * Velocity
10. P K Mallik
Estimation Types
• Velocity = 40 for 3 member team
• Duration = 16 Weeks (+ 2 weeks for pre and
post release)
• Iteration Length = 2 Weeks
• Available Story Points (16 / 2) * 40 = 320
• Duration = 16 weeks
• Selected Story Points = 480
• Iteration Length = 2 weeks
• Productivity = 12 Story points / iteration /
resource
• Story Points with 1 person = (16 / 2 ) * 12 =
96
• Team Size = 480 / 96 = 5
• Team Size = 5
• Selected Story Points = 540
• Iteration Length = 2 weeks
• Velocity = 60
• iterations = 520 / 60 = 9
• Duration = 9 * 2 = 18
Fixed Duration Variable Team Size Fixed Duration Fixed Team Size
Variable Duration Fixed Team Size
11. P K Mallik
Agile Planning – Prioritization
• User Stories grouped into themes as it is difficult to estimate the value of a single user story
• Prioritization done by themes and then by user stories within a theme, by product owner on the
basis of one or more factors, depending upon the theme
• Priority determines order in which themes are planned during release
Value
• Financial value in terms of revenue or savings
• Revenue can be new, incremental or retained
(revenue would otherwise be lost)
• Savings can be operational efficiencies (time,
employee turnover, training, quality)
• Value calculated as NPV where realisation is
over time
Cost
• Costs in terms of manpower and technology to
develop and maintain the feature
• Cost changes over time hence there could be a
saving if features are developed early or late
• Cost per story point is useful I order to get a
quick cost estimate
Learning
• Amount and significance of learning and new
knowledge created by developing the feature
• Product learning (what is being developed)
• Project learning (how it is developed)
• Product and project uncertainty reduce over
time as knowledge increases
Risk
• Amount of risk removed by developing the
feature
• Risks can be schedule, cost, functionality,
technology and business
• Risk should be combined with value to
determine priority (high risk/high value first
low risk/low value last)
Factors for Prioritization
12. P K Mallik
Prioritisation – Thumb Rules
• For projects on new technology or having a team unfamiliar with the
technology the first few iterations should be prioritised by Learning i.e.
the user stories where the team learns the most should have high priority
• For projects which have a high cost or penalty for delays, high risk user
stories should have a high priority
• For product development, user stories with a high business value to the
product vendor should have a high priority
• For all other projects, user stories with a high business value to the client
should have a high priority
• Cost can be secondary criteria for prioritisation
13. P K Mallik
• Each iteration will contain analysis,
design, coding and testing stages
• Iterations are Time-Boxed (finish on time
even if functionality or features have to
be dropped)
• At the start of an iteration any new
knowledge gained from earlier iterations
is incorporated in the plan
• Iterations focus on delivering user-value
based features (User Stories).
• Each iteration ends with features and
functionality tested to release quality
(ready to be included in the release for
additional testing)
• Features and Functionality included in
each iteration must minimize technical
dependencies on each other
Iterations
Iteration 1 Iteration 3 Iteration 5 Iteration 6 Iteration7Release
Iteration 2
Iterations
US !
US 2
US 3
US 4
US 5
US 6
US 7
US 8
US 9
US 10
UserStories
Analysis
Release
Ready
Design Coding Testing
Iteration 4
Iteration 4
Release Till
Date
Iteration 4
Output
User Stories can be expressed as “As a <type of user>
I want <capability> so that <business value>”
14. P K Mallik
Framework
Pre-sales
Epics
Effort Estimate Contract
Estimates
Sizing
RFP Scope
Story Points
Milestone Dates
Delivery – Requirements & Design
Architecture
Requirement Analysis
Epic Disassembly
High Level Design
ReleasePlan
Delivery – Development and Testing
DetailedDesign/FnSpec
Delivery – Acceptance
UAT
Iteration Plan Coding and UT
Module Integration Testing
Task Assignment
HLD
Templates
Standards
Common Components
Entities Attributes and Relations
Code
Configuration
NFR Testing
Walkthrough
Production
Story Sizing
Maintenance
Backlog Iteration Plan Code and UT Regression Testing Release
Acceptance Test Plan
Low Level Design
15. P K Mallik
Project Life Cycle
Scope (Epics/Themes)
High Level Design
Release Plan
Iteration Plan
Low Level Design/FS
Code
Unit Testing
Module Integration Testing
NFR Testing
Acceptance Test Plan
Factory Acceptance Testing
System integration Testing
User Stories
Epics/Themes
Key Components and Entities
Sizing and Effort
Release
Iteration
Application/Product
SA
Product Owner
Developer
Tester
Project Manager
Standards and Templates
TA
Proof Of Concept
Key Component
Configuration
NFR TestingUAT
UAT
16. P K Mallik
Offshore
Onsite
Onsite
Onsite Offshore Model
Scope (Epics/Themes)
High Level Design
Release Plan
Iteration Plan
Low Level Design/FS
Code
Unit Testing
Module Integration Testing
NFR Testing
Acceptance Test Plan
Factory Acceptance Testing
System integration Testing
User Stories
Epics/Themes
Key Components and Entities
Sizing and Effort
Release
Iteration
Application/Product
Standards and Templates
Proof Of Concept
Key Component
Configuration
NFR TestingUAT
UAT
18. P K Mallik
Project Plan
Release 1
Release 2
Build
Analysis and Design
UAT
Iteration 1
LLD Build Test
Iteration 2
LLD Build Test
Iteration 3
LLD Build Test
Analysis and Design
Iteration 1
LLD Build Test
Build UAT
Iteration 1
LLD Build Test
Iteration 1
LLD Build TestSA Design/Sizing/Estimate Mentoring UAT SupportDesign/Sizing/Estimate
TA Standards and Templates NFR Review & Fixes
PM Planning and Staffing Monitoring and Change Controls
Start-up
Scope/
Backlog
Defects
19. P K Mallik
Techniques
DSDM Atern
High Level
Requirements
(Epics)
Priority (Value, Risk, Learning, Cost)
Release Plan
Schedule Budget
Acceptable
Quality
Features
Release
Foundation
User Stories
High Level
Design
Standards
Templates
Proof of
Concept
Governance and Organisation
Business
Case
Iteration Plan
Iteration
MoSCoW
SCRUM
XP
Length Velocity
Quality
Features
20. P K Mallik
MoSCoW is often used with time-boxing, where a deadline is fixed so that the focus can be on the most important requirements, and as such is seen as a core
aspect of rapid application development (RAD) software development processes, such as Dynamic Systems Development Method (DSDM) and agile software
development techniques
MoSCoW
• The technique is used to prioritise features at a high level each feature is
classified as
– M - MUST: Describes a requirement that must be satisfied in the final solution for
the solution to be considered a success.
– S - SHOULD: Represents a high-priority item that should be included in the solution
if it is possible. This is often a critical requirement but one which can be satisfied
in other ways if strictly necessary.
– C - COULD: Describes a requirement which is considered desirable but not
necessary. This will be included if time and resources permit.
– W - WON'T/WOULD: Represents a requirement that stakeholders have agreed will
not be implemented in a given release, but may be considered for the future.
• The team would iterate through the features until the final mix of
requirements for the release are as follows (in terms of Story Points)
– M – 50% at most
– S – 30%
– C – 20%
• Percentages may vary but the Must category should not exceed 80% of
effort if release has to have a good chance of success
21. P K Mallik
DSDM Atern
• Focus on the business need. Delivering a perfect
system which addresses all possible business
needs is less important than focusing on critical
functionalities.
– Understand the true business priorities
– Establish a sound Business Case
– Seek continuous business sponsorship and
commitment
– Guarantee the Minimum Usable Subset of features.
• Deliver on time
– Time box the work
– Focus on business priorities
– Always meet deadlines
• Never compromise quality
– Set the level of quality at the outset
– Ensure that quality does not become a variable
– Build in quality by constant review
– Plan to test early and continuously. See test-driven
development for comparison.
Schedule Budget
Acceptable
Quality
Features
• Define quality strategy
• Identify stories for release
• Ensure stories can fit into release timeframe
• Prepare a high level release plan
22. P K Mallik
Post GameGamePre Game
Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
SCRUM
24 hours
Product
Backlog
As prioritized
by Product
Owner
Planning
& High Level Design
Sprint Backlog
Backlog tasks
expanded
by team
Potentially Shippable
Product Increment
Daily Scrum
Meeting 14-30 day Sprints
Develop
Adjust
Wrap
Review
23. P K Mallik
SCRUM Roles
• Product Owner
– Filled by the customer representative, Product Manager or a person who represents the
interests of the customer.
– Responsible for creating the initial overall requirements and release plans.
• Scrum Master
– Filled by the Project Manager.
– Responsible for the scrum process and for implementing scrum.
– Ensuring that everyone follows Scrum rules and practices
– Main job is to remove impediments
• Team
– Team is collectively responsible for developing functionality within an iteration and
managing their own work to do so.
– Team are self-managing, self-organizing and cross-functional.
– Team would typically consist of designers, developers, and QA persons
– Typically consists of 3-7 people.
– Members are expected to be full-time.
24. P K Mallik
SCRUM Concepts
• A sprint begins once the entire scrum team along with the product manager is
comfortable with all the features on the product backlog
• The scrum team then chooses the highest priority feature from the product
backlog and makes it the Sprint Backlog. This is typically the amount of work
that the scrum team thinks it can finish in one Sprint. Sprints are usually one
month long.
• The Scrum team expands the Backlog into tasks that are 4-16 hours in length.
These are called miniature milestones or inch-pebbles. The remaining time on
the tasks is updated each day. The Sprint ends with a demonstration of the
system to all the stakeholders involved in the project.
• The scrum team is given full authority to complete the sprint backlog by the
end of the sprint considering budget constraints for the project. The most
important thing about the Sprint is that no outside influence can interfere with
the Scrum team until the end of the Sprint.
• The scrum team is usually made up of 7 ± 2 members. If the number exceeds
this, the group must be split into two or more scrum groups and if the number
is less than the prescribed amount, the team may lose its dynamics.
25. P K Mallik
SCRUM Methodology
• Daily Scrum is the short 15 minute meeting that is conducted everyday
– Parameters
– Daily
– Same time same place (penalty for late coming)
– Stand up meeting
– 15 minutes
– Three questions
• What did you do yesterday?
• What will you do today?
• What obstacles are in the way?
– Not for Problem solving
– Meeting for resolving obstacles or sharing of information can be arranged separately
– Attendees: Team and Scrum Master
• Nobody other than the scrum team can participate in the meeting; however, it
can be attended by anyone else
• The first two questions allow the Scrum Master to monitor the process
qualitatively.
• The third question gives the Scrum Master all the information they need to help
the team work better.
26. P K Mallik
Some New Working Models
•Whiteboard - ‘Big Visible Charts’ or ‘Information
Radiators’ with every team
•Scrum ‘Stand-ups’ use the BVC/IR
•Data Extracts using Excel Macro aggregation for
reporting
•Meetings aren’t meetings unless everyone inputs
•One Team, One Vision, Equal Accountability
27. P K Mallik
Ron Jefferies : Outside your extreme programming project, you will probably need documentation: by all means, write it. Inside your project, there is so much
verbal communication that you may need very little else. Trust yourselves to know the difference
XP (eXtreme Programming)
• XP is the only method that provides deep and profound disciplines for the way
developers do their daily work.
• Of those disciplines, Test Driven Development is the most revolutionary and
impactful
• XP can be used tactically to deliver complex features or technically challenging
solutions
29. P K Mallik
Adapted from Object mentor -- http://www.objectmentor.com/omSolutions/agile_what.html
XP Processes
• Envisioning : Team gathers requirements and identifies risks. Requirements are
entered into a requirements backlog and risks are entered into a risk backlog.
• Definition : Product requirements are converted into product features
containing concrete use cases and acceptance criteria.
• Estimation : Developers prepare estimates for the stories and compare their
estimates to the original estimates created during the definition phase.
Discrepancies or anomalies between the estimates are resolved through
negotiation. T
• Development : Done iteratively and incrementally using Test Driven
Development Model and a Continuous Build and Integration Environment. Test
are written for each unit of code and only code that passes its test is
committed to the build. Every two weeks, the development team delivers
working stories that pass their tests.
• Release Engineering : Performed on an ongoing basis as the development
proceeds and the product evolves.
• Continuous Testing : Unit tests and end-to-end acceptance tests are run from
day one to ensure the overall continuity and integrity of the system as a whole.
me.
32. P K Mallik
Adapted from Object mentor -- http://www.objectmentor.com/omSolutions/agile_what.html
Agile Practices
• Acceptance Testing : The tests demonstrate that the story is complete. The
programmers and the customer automate acceptance tests. Programmers run the tests
multiple times per day.
• Coding Standards : The code needs to have a common style to facilitate
communication between programmers. The team owns the coding style.
• Collective Ownership: The team owns the code. Programmer pairs modify any piece
of code they need to. Extensive unit tests help protect the team from coding
mistakes.
• Continuous Integration : Programmers integrate and test the software many times a
day. Big code branches and merges are avoided.
• Customer Team Member : Teams have someone (or a group of people) representing
the interests of the customer. They decide what is in the product and what is not in
the product.
• Pair Programming : Two programmers collaborate to solve one problem. Programming
is not a spectator sport.
• Refactoring : As programmers add new features to the project, the design may start
to get messy. If this continues, the design will deteriorate. Refactoring is the process
of keeping the design clean incrementally.
• Test Driven Design : Programmers write software in very small verifiable steps. First,
we write a small test. Then we write enough code to satisfy the test. Then another
test is written, and so on.
33. P K Mallik
Planning
• Release Plan is a high level plan covering 3 to 12 iterations
• Determines how much will be developed and the duration before the next
releasable product
• Provides context for iterations to combine into a satisfying whole
• Planning Process
– Determine “Conditions of Satisfaction” (criteria to determine project success or failure). For
most projects this will be money saved or generated
– Estimate user stories (usually at the theme or epic level)
– Select iteration length (usually 2 to 4 weeks)
– Estimate Velocity based upon team experience with technology and business domain
– Prioritize User Stories based upon value, cost, learning and risk
– Determine Release Date based on scope or set release date if project is date-driven
– Assign user stories to iterations (for next 2 or three iterations)
– Periodically revise release plan based on development teams velocity
• Velocity based on historical values, trial run, forecast based on availability and
utilisation
34. P K Mallik
`
`
Iteration
Agile Plan
Application Backlog
• Requirement Backlog
• Change Requests/Enhancements
• Defects
PrioritiseUser Stories
Release
Release Backlog
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Task 1
Task 2
Task 3
Build Test
Detailed
Design
High Level Design
Acceptance Criteria
Test Plan
Non Functional
Test Plan
Non Functional
Test
Rework
Delivery
Packaging Installation UAT NFR Testing SIT
35. P K Mallik
Task Board
• Task board for team to organise work and show pending tasks
• Tests ready column shows if high level tests are ready
• Story card shows story points at bottom, task card shows hours and initials of
resource when assigned
• The ‘To Verify’ column contains the test or review activity associated with a task
• Iteration burn-down charts are similar to release burn-down except the ‘x’ axis
shows days instead of iterations
Story To Do Test Plans In Process To Verify Hours
User
Story 1
Task 1Task 2
Ready
Task 3
User
Story 2
Task 1
Task 3
Task Board
5
3 7
4
2
6
2
Task 4
5
Task 2
2
19
10
AR
ST
PP
LR
36. P K Mallik
Agile Tracking – Release
• Track requirement changes and how they affect the target.
Revised estimates may drive delivery date further away as
a result real progress may be less than execution
• Calculate progress based on stories that is complete,
partially finished work should be ignored
– Hard to measure unfinished or incomplete work
– Stories that cannot be completed need to be resolved by
developers and customer
– Unfinished work leads to work in process. Large amount of
work in process delays feedback and learnings
• Release burn-down charts used to track remaining work.
Shows points balance at the end of each iteration
– Line charts show net points balance
– Bar charts show points balance and velocity but is more
difficult to understand
– Parking Lot charts provides stories, story points and percentage
complete in one box for each theme or epic
1 32 54 6
240
0
40
80
120
160
200
Iterations
StoryPoints
1 32 54 6
-20
0
40
80
Iterations
StoryPoints
20
60
Points Added
Points Removed
Velocity
Theme 1
12 Stories
51 story points
50%
37. P K Mallik
Agile Guidelines
1. The whole team should be involved in planning and estimation even though primary
responsibility for some activities fall on individuals
2. Planning must be done at different levels (release, iteration and daily) with higher levels of
precision
3. Estimates of size and duration must be kept separate
4. Plans must express uncertainty in either functionality or dates depending upon whether
duration or functionality is fixed
5. Re-plan at the start of each iteration to assess the relevance of the release plan
6. Track and communicate progress to all stakeholders
7. Understand that a project is as much about generating new knowledge as about adding new
capabilities to the product
8. Functionality which will be added in the near future must be disassembled to smaller user
stories (taking 2 to 10 days to complete)
9. Prioritize features to optimize total value, eliminate high risk items early, move items that
provide significant learning as high as possible
10. Base estimates and plans on facts (real observer values)
11. Plan some slack for team members availability, utilisation and productivity
12. Co-ordinate across teams through look-ahead planning in projects with multiple teams
