Agile Techniques

P K Mallik

Approach, Techniques and Tools

Agile Techniques

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


0.5 6 Individual Information Capture

Single state policy processing


2 24

Support different policy terms

Quote Creation Single state policy processing

0.75 18

Agent business support


1.5 36

Insured as a Common entity


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

Agile Techniques

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)

http://www.agiledata.org/essays/tdd.html

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

Agile Detailed – Tracking

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


NFR Testing


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


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


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


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

P K Mallik

Thank You

Agile Techniques

Documents

Transcript of Agile Techniques