Upload
pk-mallik
View
34
Download
1
Embed Size (px)
Citation preview
P K Mallik
• Objectives• Key Benefits• Key Concepts• User Stories• Estimation• Planning• Techniques• Tools• Models• Guidelines
Agile Techniques
P K Mallik
Objectives• Create clear business value across stakeholders• Improve predictability of project and product delivery• Create environment where deviations are the exception
P K Mallik
Key Benefits• Shorter Planning Horizon – Greater Predictability • Empowering the teams – Reduce Costs Through Better Resource
Mix• Customer Collaboration – Value Delivery by meeting the needs• Iterative Approach – Greater Flexibility
P K Mallik
Key ConceptsTerm Description ExampleEpic A very large user story, needs to be split
into smaller stories to fit the iterationsMember 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 pointsMember registration 14 story pointsPurchase 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 accessIteration 2 : Member Registration Contact DetailsIteration 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
P K Mallik
User Stories are a means of capturing requirements at a high level and should not be used as a basis for detailing the requirement and not as a format to capture detailed requirements
User Stories• Developed and ‘owned’ by the Product Owner• Written from the stakeholder’s, i.e. the user’s perspective• Focus on the ‘what’ not the ‘how’• VERY lightweight (typically one sentences)• Describes functionality of value to the user or purchaser of the
software. • User Stories are composed of the following aspects
– A written description for planning and as a reminder– Conversations about the story that flesh out the details– Tests to determine when the story is complete
• User stories are captured using a Story Card which is a physical or electronic note
• Examples of User Stories– An user can register as a member– An user can select goods for purchase– An user can pay using credit cards
P K Mallik
Story Structure• AS A…Accounts Administrator
• I WANT TO…Search for Outstanding Invoices
• SO THAT I CAN…select one to chase the Debtor
• Acceptance Criteria– Can I search by Date, Company and Invoice Value Range(s)?– Does the result list display in date order, and can I change this to order by
any column in the list?– If the results are large, does the system warn me, and suggest narrowing
my search?
P K Mallik
Myths
1. No DocumentationDocumentation is required.
Current artefacts will continue to be produced
Main changes are in Project, Release and Iteration (Sprint) plan
2. No QMSQMS is very much applicable
Only planning process is different
Existing Processes & Templates will apply for deliverables
3. No DashboardAgile metrics can be mapped to dashboard
Metrics calculations are somewhat different from current formulae
Dashboard can be generated with equivalent numbers
4. No ePMOAgile tools will maintain project related data
Data import feasibility is being worked out
Once completed ePMO reports can be generated using imported data
P K Mallik
Epic, Feature, Sub Feature, Story, TasksE
pic
Sto
ry
Feature1
Sub-Feature (SP) User Story(SP)
Task 1 (hrs)
Task 2 (hrs)
Task 3 (hrs)Sub-Feature (SP)
Feature2 Sub-Feature (SP)
User Story (SP)
Task 1 (hrs)
Task 2 (hrs)
User Story (SP)
P K Mallik
A story card is a reminder to developers and customers to have a conversation and is not a requirement in itself
Creating User Stories• Aggregate users into types/role
– Insured– Agent– First time user
• Actively involve customer/users • Avoid dependencies between stories
– E.g. If a user can login from multiple channels these should not be different stories– Dependent stories should be combined into a larger story
• Stories are short descriptions of functionality details of which can be negotiated in conversations
• Important details may be included in the story card as annotations (such as which payment channels will be available)
• Stories must be valuable to the purchaser/user of the software• Stories which are valuable only to developers should be avoided e.g. the
application should be stateless• Developers should be able to estimate the user story. If they lack domain
knowledge they should discuss with the customer to arrive at the estimate• Stories should be testable. Tests should verify if the story is complete. Test
criteria may be captured at the back of the Story Card
Test for card rejection
Test for successful debit
Test for transaction being cancelled by user
As an policy holder I would use my credit card to pay my
premiums
Note: Will policy holder pay through direct debit?
Note: How will late payments be managed
Note: Can we use payment gateway
P K Mallik
Creating a Good Story• Start with stories which are associated with a goal
– As an agent I want t find view upcoming renewals– As a insured I would like to be prompted for renewals
• Split up large stories into smaller pieces that are easier to manage, plan, estimate and test
• Write Closed stories that finish with the achievement of a meaningful goal– As a Portfolio manager I want to reviews new content before publication
to ensure adherence to web content standards– As an agent I want to be able to send emails to all my customers– As a regional manager I want to suspend an agent for verifying their
account• Annotate the card with constraints for example
– Payment: must be PCI compliant– Search for Renewals: results page must load within 30 seconds
Suggested Format: As a <role> want <function> so that <value/benefit>
P K Mallik
Splitting a Story• A story needs to be split
– If it is bigger than the iteration– If it is too complex to test– To create a more accurate estimate from the parts
• A story can be split– Across data boundaries, by type of data being captured/updated (each type being a
separate data creation/update form)– By separating error and exception handling– Across operational boundaries, by creating a sub-story for each part of the process (e.g.
search criteria, query generation, data display)– Across boundaries of a CRUD operation– By isolating it from cross-cutting concerns (such as role based access and data visibility)– By separating functional (such as query criteria) and non-functional (such as
performance) aspects – Based on priority, by separating low and high priority items
• A story should not be split by activity (such as code the UI, write the middle tier etc., these are tasks)
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.
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
P K Mallik
Agile Estimation by Planning Poker
• Combines analogies, expert opinion and disaggregation to achieve quick and reliable estimates
• Participants include all members of delivery team involved in the iteration, one person plays the role of moderator.
• Each member is given a set of cards with numbers as per the predefined buckets (0,1,2,3,5,8 etc.)
• Product Owner should be available to answer any queries
• For each story/theme/epic each member selects a card, cards are displayed once all members have made their selection
• After the first round estimators can explain the basis for their estimate (specially the high and low estimates)
• After discussions a fresh round of estimation is done
• This process is repeated until convergence is achieved
US !
US 2
US 3
US 4
US 5
US 6
US 7
US 8
US 9
US 10
User
Sto
ries 1
2
3
5
Plan
ning
Pok
er
User Story Size Estimates
Convergence
Discuss High Low
Estimates
NoEnd Yes
Sizing Buckets
For estimating before the project starts the project team needs
to be split into smaller teams and each assigned a sub-set of
user stories
P K Mallik
Estimating by Relative ComplexityStory/Epic/Theme Parents
Epic/ThemeBaseline Relative
ComplexityStory Points
Baseline
Quote Creation NA 179
Individual Information Capture
Quote Creation Individual Information Capture
1 12 Individual Information Capture
Individual Information Update
Quote Creation Individual Information Capture
0.5 6 Individual Information Capture
Single state policy processing
Quote Creation Individual Information Capture
2 24
Support different policy terms
Quote Creation Single state policy processing
0.75 18
Agent business support
Quote Creation Single state policy processing
1.5 36
Insured as a Common entity
Quote Creation Single state policy processing
0.5 12
Insured as a Private entity
Quote Creation Insured as a Common entity
0.75 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
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
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
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
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 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
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
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
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
Meeting14-30 day Sprints
Develop
Adjust
Wrap
Review
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.
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.
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.
P K Mallik
SCRUM Tracking –Task Board• 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
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
ReadyTask 3
User Story 2 Task 1
Task 3
Task Board
53 7
4
26
2
Task 45
Task 22
19
10
AR
ST
PP
LR
Task 1
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
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.
P K Mallik
Source : http://www.agiledata.org/essays/tdd.html
Test Driven Development (TDD)
P K Mallik
Source : http://msdn.microsoft.com/en-US/library/aa730844(v=VS.80).aspx
TDD Process• Understand the requirements of the story, work item, or feature that you are working on.• Red: Create a test and make it fail.
– Imagine how the new code should be called and write the test as if the code already existed. You will not get IntelliSense because the new method does not yet exist.
– Create the new production code stub. Write just enough code so that it compiles.– Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct
code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.• Green: Make the test pass by any means necessary.
– Write the production code to make the test pass. Keep it simple.– Some advocate the hard-coding of the expected return value first to verify that the test correctly detects
success. This varies from practitioner to practitioner.– If you've written the code so that the test passes as intended, you are finished. You do not have to write
more code speculatively. The test is the objective definition of "done."– When the test passes, you might want to run all tests up to this point to build confidence that everything
else is still working.• Refactor: Change the code to remove duplication in your project and to improve the design
while ensuring that all tests still pass. – Remove duplication caused by the addition of the new functionality.– Make design changes to improve the overall solution.– After each refactoring, rerun all the tests to ensure that they all still pass.
• Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/Refactor cycles.
P K Mallik
Test
Deployment
Test
Triage
Fix
Install SIT
Test
Triage
Fix
Install NFR
Test
Triage
Fix
Install UAT
Train
Training
Implement
Course Material
Documents
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.
P K Mallik
Agile Tracking – Burn Down Charts• 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
Stor
y Po
ints
1 32 54 6-20
0
40
80
Iterations
Stor
y Po
ints
20
60
Points Added
Points Removed
Velocity
Theme 1
12 Stories
51 story points
50%
P K Mallik
Metrics• Working software shipped on time and cost per Sprint• Story-points delivered/Sprint/period/cost• Burndown rate• % Technical debt/Sprint n/time• Automated Unit Test Pass rate • Build failure rate• Unit Test Coverage • Deployment test pass rate• %Code coverage/Sprint/time• LOC completed etc.• Defects detected per Story Point• Defects detected per Sprint• Defects detected/time
P K Mallik
Agile Tool – Releases Planned
Submission Info (Quote & App Entry) for Business Auto
Submission Info (Quote & App Entry) for Garage
Submission Info (Issuance) for Business Auto & Garage
Endorsement
Import/Export
CSR
Output Forms XML
Ready For Demo to
Prospects
Ready For First
Implementation
Ready For Demo to Pre-
Sales
P K Mallik
Agile Tool – Release Level Plan & Review
Issues include User Stories, Tasks, Bugs
Scope of Sprint
P K Mallik
Agile SCRUM - Task Board for Daily Standup
Remaining Efforts for
Task Close User Story
when All
Associated Tasks
are Closed
Story Points
P K Mallik
Release Tracking – Burndown (post Iteration)
2
0
Based on current velocity,
team is expected to
complete 368 – 20 = 348
story points
Snapshot at
Release 1 - Sprint 2
completion
P K Mallik
Process Improvements (post Iteration)
Retrospective• Retrospectives are regular reviews of the team, by the team, to discuss how
they are working
• Retrospective format– What works (clear wins)?– What doesn’t work so well?– What do we need to start doing?
• Info gathered from everyone
• A broad range of topics, not in depth– Get Issue list/ impediments /notes created
P K Mallik
Agile Delivery Model
Business Case
Application
Release
Sprint
Factory Acceptance
User Acceptance
System Integration
Deployment
Valu
e Re
alisa
tion
Func
tiona
l
Tact
ical
Stra
tegi
c
Busin
ess
P K Mallik
Agile Coverage
Level 0 – Start up Level 1 – Basic
Level 2 – Advanced Level 3 – Enterprise
Busi
ness
Func
tion
alTa
ctic
alSt
rate
gic
Busin
ess V
alue
P K Mallik
Project Framework
Pre-sales
Epics
Effort Estimate Contract
Estimates
Sizing
RFP Scope
Story Points
Milestone Dates
Delivery – Foundation
Architecture
Requirement Foundation
Management Foundation
Solution Foundation
Release Plan
Delivery – Development and Testing
Detailed Design/Fn Spec
Delivery – Acceptance
UAT
Iteration Plan Coding and UT
Module Integration Testing
Task Assignment
HLD
Templates
Standards
Common Components
Entities Attributes and Relations
Code
ConfigurationNFR Testing
Walkthrough
Production
Feature Sizing
Acceptance Test Plan
P K Mallik
`
`
Iteration
Agile Plan for Projects
Application Backlog• Requirement Backlog• Change Requests/Enhancements• Defects
PrioritiseUser Stories
ReleaseRelease Backlog
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Task 1
Task 2
Task 3Build Test
Detailed Design
High Level Design
Acceptance Criteria
Test PlanNon Functional Test
Plan
Non Functional Test Rework
DeliveryPackaging Installation UAT NFR Testing SIT
Detailed
Requirement
High Level Reqmnt
P K Mallik
Offsh
ore
Onsite
Onsite
Project Life CycleScope (Epics/Themes)
Solution Architecture
Release Plan
Iteration Plan
Low Level Design
Code
Unit Testing
Module Integration Testing
NFR Testing
Acceptance Test Plan
Factory Acceptance Testing
System integration Testing
User Stories
Release Backlog
Requirements Overview
Sizing and Effort
Rele
ase
Itera
tion
Appl
icatio
n/Pr
oduc
tStandards and Templates
Prototypes
Key Component
Configuration
NFR TestingUAT
UAT
SA
Product Owner
Developer
Tester
Project Manager
TA
BA
Enterprise Architecture
High Level Requirements
Detailed Requirements
Governance Model
HLD
P K Mallik
Model 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
P K Mallik
Product Implementation Framework
Pre-sales
Gaps
Effort Estimate Contract
Estimates
Sizing
Product Features
Story Points
Milestone Dates
Delivery – Gap analysis
Platform
Installation
Base Testing
Base Configuration
Release Plan
Delivery – Development and Testing
Gap Details/Data Mapping
Delivery – Acceptance
UAT
Iteration Plan Coding and UT
Data Migration
Task Assignment
Bespoke Components
Gap Identification
Defects List
Acceptance Test Plan
Code
ConfigurationNFR Testing
Walkthrough
Production
Demonstration
Configuration and Merging
NFR Testing
P K Mallik
`
`
`
Iteration
Product Implementation Plan
Application Backlog• Requirement Backlog• Enhancements• Defects
PrioritiseFeatures
Enhancements
Defects
ReleaseRelease Backlog
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Task 1
Task 2
Task 3Gap Detailing Test
Configure and
Demonstrate
Configuration and Demo
Migration Plan
Build and
Reconfigure
Non Functional Test
Plan
Non Functional Test Rework
Gap Analysis
DeliveryInstallation Configuration Merging UAT SITMigrate Data
P K Mallik
Offsh
ore
Onsite
Onsite
Product Implementation Life CycleScope (Features and Gaps)
Base Installation
Release Plan
Unit Testing
Module Integration Testing
NFR Testing
Factory Acceptance Testing
Integration Testing
Features/Gaps/Defects
Identify Gaps
Sizing and Effort
Rele
ase
Itera
tion
Prod
uct
BA
Product Owner
Developer
Tester
Project Manager
Gap Estimate
TA
Configuration
NFR TestingSystem Integration Testing
Data Migration
UAT
Manage Base Defects
Migrate Data
Iteration Plan
Code
Acceptance Test Plan
User Stories (features and gaps)/Defects
Base Changes/Fixes
Gap Detailing Design
Demo (Model Office)
Base Configuration
P K Mallik
Features
Enhancements
Defects
Model Product Implementation Plan
Release 2
Implementation FAT
Iteration 1Design Build Test
Base
Installation
NFR
Base
Configuration
Demo
Design Build TestDemoIteration 2
Config Build TestDesignIteration 3
Release 1
Implementation FAT
Iteration 1Design Build Test
NFR
Demo
Iteration 1Design Build TestDemo
Iteration 1Design Build TestDemo
New Feature
Build consists of both
coding and
configuration
Depending upon the
change, the
configuration
effort can vary from 0 to
100%
Pre Sales
Discovery and Gap
AnalysisConfiguration
Feature List High level Gaps
High level demonstration and gap analysis to configure product for detailed demo
and gap analysis
Cost and Schedule
Base installation is done on the basis of Pre Sales discussions and identified gaps. Product certified by certification
team.
Merger
P K Mallik
Agile Guidelines1. The whole team should be involved in planning and estimation even though primary
responsibility for some activities fall on individuals2. Planning must be done at different levels (release, iteration and daily) with higher
levels of precision3. Estimates of size and duration must be kept separate4. Plans must express uncertainty in either functionality or dates depending upon
whether duration or functionality is fixed5. Re-plan at the start of each iteration to assess the relevance of the release plan6. Track and communicate progress to all stakeholders7. Understand that a project is as much about generating new knowledge as about
adding new capabilities to the product8. 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 possible10. Base estimates and plans on facts (real observer values)11. Plan some slack for team members availability, utilisation and productivity12. Co-ordinate across teams through look-ahead planning in projects with multiple teams