pmi

PMI -Agile Certified 
Practitioner 
Keshav Kumar, PMP, PMI- ACP 
PMI -Agile Certified 
Practitioner 
Keshav Kumar, PMP, PMI- ACP 
Sunday 10 March 13 



Agenda 


Introduction to PMI and PMI-ACP 




Introduction to Agile Project Management 
Agile Fundamentals 
Agile Planning 
Agile Communication 
Agile Estimation 
Agile Metrics 
Agile Leadership 
Agile Contracts 
Agile Methodologies 
Q and A 


Sunday 10 March 13 



Introduction to PMI 
and PMI-ACP 
Introduction to PMI 
and PMI-ACP 
Sunday 10 March 13 



Introduction to PMI and PMI-ACP 
About PMI 
PMI Certifications 
About PMI -Agile Certified Practitioner 
Introduction to PMI and PMI-ACP 
About PMI 
PMI Certifications 
About PMI -Agile Certified Practitioner 
Sunday 10 March 13 



About PMI 
World’s largest Professional membership association 
More than half a million credential holders 
Not for Profit Organization 
World’s largest Professional membership association 
More than half a million credential holders 
Not for Profit Organization 
Sunday 10 March 13 



PMI Certifications 






Certified Associate in Project Management (CAPM) 
Project Management Professional (PMP) 
Program Management Professional (PgMP) 
PMI Agile Certified Practitioner (PMI -ACP) 
PMI Scheduling Professional (PMI -SP) 
PMI Risk Management Professional (PMI -RMP) 




Sunday 10 March 13 



PMI - ACP Exam Information 






PMI-ACP Exam Blue Print 
Agile Tools and Technique -50% 
Agile Knowledge and Skills -50% 




Exam Information 
Total number of question -120 
Scored questions -100 
Un-scored questions -20 




Sunday 10 March 13 



Agile Tools and Techniques Agile Tools and Techniques 
Sunday 10 March 13 



Agile Knowledge and Skills Agile Knowledge and Skills 
Sunday 10 March 13 



Agile Knowledge and Skills Cont... Agile Knowledge and Skills Cont... 
Sunday 10 March 13 



Agile Knowledge and Skills cont... Agile Knowledge and Skills cont... 
Sunday 10 March 13 



Introduction to Agile 
Project Management 
Introduction to Agile 
Project Management 
Sunday 10 March 13 



Challenges inTraditional Project Methodologies 






Rigid and Resistant to Change even if change is good for the project 




Can become more focussed on processes rather than the product 




Heavy front-up analysis 


Commit to technical solution very early 


Customer are forced to sign-off on requirements very early in the project 


life cycle and have to wait for long time before getting a chance to test the 
product 
Too much documentation 


Sunday 10 March 13 



Sunday 10 March 13 



Why Traditional planning fails? 






Planning by activity rather than features 
Activities don’t finish early 
Lateness is passed down the schedule 
Activities are not independent 
Multitasking causes further delays 
Features are not developed by priority. 
We ignore uncertainty 
Estimates become commitments 




Sunday 10 March 13 



Introduction to Agile Methodologies 


Group of Software Development 
Methods based on iterative and 
incremental development 


Requirements and solutions evolve 
through collaboration between self 
organizing and cross functional team. 


Favors adaptation 


Time-Boxed iterative approach 


Encourages change even late in 
development cycle 




Sunday 10 March 13 



Agile Vs.Waterfall Methodologies Agile Vs.Waterfall Methodologies 
Sunday 10 March 13 



Agile Vs.Waterfall Agile Vs.Waterfall 
Sunday 10 March 13 



Agile Vs.Waterfall Agile Vs.Waterfall 
Sunday 10 March 13 



Agile Manifesto Agile Manifesto 
Sunday 10 March 13 



Sunday 10 March 13 



Embracing changes 






Agile projects not only accept but also welcome changes (“Welcome 
changing requirements, even late in development” -Principles behind agile 
manifesto) 


Agile projects is not just for team. It also gives competitive advantage to 
customer as well by enabling them to respond quickly to changes 


Sunday 10 March 13 



Agile Fundamentals Agile Fundamentals 
Sunday 10 March 13 



Agile Fundamentals 






Product Vision 
Product Roadmap 
Product Backlog 
Minimally Marketable Features 
User Stories 
Story Maps 
Personas 
Epics 
Themes 


Sunday 10 March 13 



Product Vision Statement 
One of the first thing that a team(typically product owner)develops. 
Elevator statement for the product, describing what it is, who would need it, 
sponsors and what differentiates it in the marketplace. 
One of the first thing that a team(typically product owner)develops. 
Elevator statement for the product, describing what it is, who would need it, 
sponsors and what differentiates it in the marketplace. 
Sunday 10 March 13 



Product Roadmap 






Product Roadmap is an high level overview of each planned release and key 
features associated with releases. 
Publicly posted in the team space or in a common, high visible area. 
May span few months or even years sometime. 
Used as communication tool 
Evolves during the life cycle of the project (Agile Embraces change) 




Sunday 10 March 13 



Product Backlog 






Product backlog is list of all planned functionality for the project, sorted by 
value to customer from higher to lower. 
Product owner/customer is responsible for Product Backlog 


Product Backlog should be DEEP 
Detailed Appropriately -User stories should contain neither too 
much nor too little detail 




Estimable -User stories near the top of backlog should have enough 
detail for estimation 


Emergent -Backlog grows and change over time. It is dynamic. 
Prioritized-Stories that will deliver most values should be at the top of 
backlog 


Sunday 10 March 13 



Product Backlog Cont... Product Backlog Cont... 
Sunday 10 March 13 



Minimal Marketable Feature 
MMF -Smallest grouping of functionality that can add value to customer 
Maybe larger than user stories but should be as small as possible. 
It is customer or Product Owner’s responsibility to defined MMF 
MMF -Smallest grouping of functionality that can add value to customer 
Maybe larger than user stories but should be as small as possible. 
It is customer or Product Owner’s responsibility to defined MMF 
Sunday 10 March 13 



User Stories 






A user story describes functionality that will be valuable to either a user or purchaser of a 
system or software. 


User story consist of three parts 
Cards -Hand written description of the story used for planning and as a reminder. 
Traditionally on paper note card 




Conversation -conversations about the story that serve to flesh out the details of 


the story 
Confirmation -tests that convey and document details and that can be used to 
determine when a story is complete 


The Card may be the most visible manifestation but not the most important one 


Conversation and Confirmation are more important. Details are worked out in Conversation 
and recorded in Confirmation if for detailing 
Stories are not contractual obligation 


Sunday 10 March 13 



Examples of User Stories 






Good User Stories 
A user can limit who can search the resume 
A user can search for a job 
Organization can post the job 
A user can apply for job 




Bad User Stories 
The application would be written in C#/.NET 
The application would use Oracle Database 




Size of Stories can be measured in 
Ideal Days 
Story Points 






Sunday 10 March 13 



Feature and User Stories 






A point of Sale (Feature) can have following stories 
Collecting customer information 
Scanning bar code(s) 
Manually entering items/price/quantities 
Entering weights/measure 
Totaling the order 
Calculating tax 
Payment collection and processing 
Generating receipts 
Stories are written on note cards and known as “Story Card” 




Sunday 10 March 13 



Story Attributes 
INVEST 
Independent 
Negotiable 
Valuable to users or customer 
Estimable 
Small 
Testable 
INVEST 
Independent 
Negotiable 
Valuable to users or customer 
Estimable 
Small 
Testable 
Sunday 10 March 13 



Agile Story Smells 






ScrumMaster or coach assigning the task 
Team from one silo 
Stories are too small 
Dependent stories 
Gold Plating 
Too many details 
Including user interface details too soon 
Thinking too far ahead 
Splitting too many stories 
Customer has trouble in prioritizing 
Customer won’t write and prioritize the stories 


Sunday 10 March 13 



Story Maps 
Large story is broken down through “Disaggregation” 
Component stories need not add up to 100% of original story nor do 
estimates need to add up to original story 
Typically represented in two dimension with story cards breaking down 
the component stories 
Large story is broken down through “Disaggregation” 
Component stories need not add up to 100% of original story nor do 
estimates need to add up to original story 
Typically represented in two dimension with story cards breaking down 
the component stories 
Sunday 10 March 13 



Personas and Extreme Personas 






Personas -Fictional Character 


Personas include a name, description and even photograph 


Used to understand end users and stakeholder’s need. 


Helps to put some life into the story creating it. 


Extreme personas to ensure that as many users stories are captured as 


possible. 
Extreme personas can help capture requirements that might have been 
missed otherwise. 




Sunday 10 March 13 



Epic Stories 
Agile Epic(Sometimes called a “Capability”) -Large block of functionality 
that may span multiple iterations 
Epic stories are found lower down in product backlog. 
Agile Epic(Sometimes called a “Capability”) -Large block of functionality 
that may span multiple iterations 
Epic stories are found lower down in product backlog. 
Sunday 10 March 13 



Agile Themes 
Assigning Themes to an iteration. 
For Example, the theme for fifth iteration might be Reporting 
Indicates the functionality centered around an iteration 
Assigning Themes to an iteration. 
For Example, the theme for fifth iteration might be Reporting 
Indicates the functionality centered around an iteration 
Sunday 10 March 13 



Refactoring 






Refactoring -Reorganizing the code to align with its intended purpose 
Will not change code’s behavior 
Refactoring is often performed because of smell or because team 


recognizes the need 
A complete regression test after refactoring to ensure behavior of code has 
not changed and works the same way as it was before. 




Sunday 10 March 13 



Agile Planning Agile Planning 
Sunday 10 March 13 



Agile Planning 






Identify stakeholders and Analysis 
Planning Onion 
Agile Project Life Cycle 
Release Plan 
Iterations backlog 
Wireframe 
Last Responsible Moment Decision point 
Progressive Elaboration and Rolling wave planning 
Innovation Games 
Force Field Analysis 
Parking Lot Chart 


Sunday 10 March 13 



Identifying Stakeholder 






Stakeholder does influence the agile project... However, their role may not 
be as great as it is on traditional projects. Why? Because agile projects are 
self contained with team in its own space and customer often collocated 
with team. 


Customer/Product owner acts as the single voice of users and 
communication with other stakeholders.This keeps the team more focused 
on their work. Customer/Product owner acts as bridge between team and 
other stakeholders. 


Identify the stakeholder needs as early as possible and keep the 
communication through out the project 


Sunday 10 March 13 



Analysis 






Mis-Conception -Agile team do not perform analysis or planning and directly 
jumps to coding 


Analysis is all about understanding the problem and underlying need. 


Go straight to customer and get information first hand!.This speaks Agile value 
of individuals and Interactions and Customer Collaborations.Team may further 
engage users who can help explain the problem. 


Sunday 10 March 13 



Planning Onion 
Mis-Conception -No planning in Agile!!!! -In reality, lot more planning and 
risk mitigation in Agile.. 
Rather than comprehensive one plan, agile focuses on very frequent planning! 
Mis-Conception -No planning in Agile!!!! -In reality, lot more planning and 
risk mitigation in Agile.. 
Rather than comprehensive one plan, agile focuses on very frequent planning! 
Sunday 10 March 13 



Agile Project Lifecycle Agile Project Lifecycle 
Sunday 10 March 13 



Iteration, Release and Product Backlog Iteration, Release and Product Backlog 
Sunday 10 March 13 



Release Plan 




Release plan is high level plan for series of iterations 




Release can be Internal or External 


Iteration Zero -Primarily a planning iteration(Sometime Charter is 


written as part of iteration zero 


Iteration H -Hardening Iteration.No new features are implemented.All 
the functionality in the release is tested thoroughly 
Empty iteration backlog at the start of iteration H. 




Sunday 10 March 13 



Iteration Backlog 






Iteration backlog shows all the functionality that team would complete 




during the current iterations 
Functionality is broken down to engineering task and self organizing team 
collectively decides who will work on which task. 


Iteration backlog is maintained by the team 
Kept in a visible location for all stakeholders to see 


A backlog that is too large or too small can decrease motivation 


Sunday 10 March 13 



Wireframe 






Wireframe -Hand written/Computer rendered illustrations to showcase 
how user will interact with system 


Created quickly ==> May be changed easily 


Goal is not to get complete requirements and possibilities documented. 
Instead, this is to give users and developers some starting point to create 
useful system as efficiently as possible 




Sunday 10 March 13 



Last Responsible Moment Decision point 






Delay commitment until the last responsible moment 


Make decisions at “the moment at which failing to make a decision eliminates an important 
alternative. 


If commitments are delayed beyond the responsible moment, then default decision are made and 
one will lose the alternative option. 


By delaying the decision up to responsible moment, accuracy of your decision increase, workload 
decreases and decreases the impact of change 




Sunday 10 March 13 



Progressive Elaboration 
You do not know all the characteristics of the product at the beginning... 
Characteristics may be revisited ofter and refined... Characteristics of the 
product emerge over time...i.e. Progressively... 
You do not know all the characteristics of the product at the beginning... 
Characteristics may be revisited ofter and refined... Characteristics of the 
product emerge over time...i.e. Progressively... 
Sunday 10 March 13 



Rolling Wave Planning 
Plan in stages instead of doing very early in the project 
Details will emerge as the team gets closer to functionality 
Also used in Traditional projects 
Plan in stages instead of doing very early in the project 
Details will emerge as the team gets closer to functionality 
Also used in Traditional projects 
Sunday 10 March 13 



Definition of Done 






Common definition throughout the entire project team 


When an engineer/designer/developer/any other team member checks in a 
feature as“Done”,the meaning needs to be clear to the entire team.Work 
that is almost done may not be represented as done 


Definition of done might be tied to any combination of acceptance tests/ 
coding standards/customer sign-off/any other performance related factors 




Sunday 10 March 13 



Tasks 
Also called “Engineering Tasks” 
Specific activities the team will undertake in order to add value to system 
One user story could be broken down into a handful of actual tasks 
Self organizing team -So task will be assigned by the team itself... 
Also called “Engineering Tasks” 
Specific activities the team will undertake in order to add value to system 
One user story could be broken down into a handful of actual tasks 
Self organizing team -So task will be assigned by the team itself... 
Sunday 10 March 13 



Value Stream Mapping 
Way to analyze entire chain of process with the goal of eliminating waste.. 
Deeper understanding of the system by mapping it out.. 
Way to analyze entire chain of process with the goal of eliminating waste.. 
Deeper understanding of the system by mapping it out.. 
Sunday 10 March 13 



Force Field Analysis 
Force field analysis is way to analyze and understand the force for and against it. 
These forces are assigned a ranking(by strength) from one to four 
Force field analysis is way to analyze and understand the force for and against it. 
These forces are assigned a ranking(by strength) from one to four 
Sunday 10 March 13 



Innovation Games 






Bang for the buck -Prioritization of backlog item 
Prune the Product Tree -Shape your product to market needs 


20/20 vision -Features to be ordered from most important to less 
important 


The Apprentice -One of the team member uses existing product and other 
observes how the team member interacts with system 


Product Box -Stakeholders are asked to design a retail box that would 
entice other’s to buy. Idea is to choose most key features on box 


Sunday 10 March 13 



Agile Communication Agile Communication 
Sunday 10 March 13 



Agile Communication 






Communication Management 
Informative Workspace 
Osmotic Communication 
Agile Tooling 
Information Radiators 
Kanban Boards 
Burn-down chart and Burn-up chart 
Cumulative Flow Diagram 


Sunday 10 March 13 



Informative Workspace 
Informative workspace is all about information and accessibility. It is cockpit of entire 
development effort. 
Surround the team with information, visible to all (Hand drawn charts, 
Informative workspace broadcasts information to room 
Allows people to sense the status of the project. 
Informative workspace is all about information and accessibility. It is cockpit of entire 
development effort. 
Surround the team with information, visible to all (Hand drawn charts, 
Informative workspace broadcasts information to room 
Allows people to sense the status of the project. 
Sunday 10 March 13 



Information Radiators 
Group of artifacts used to communicate project related information to all 
stakeholders and team (status reports, status of stories etc) 
Kanban is a component of information radiator 
Ensures transparency and visibility about all the activities in the project 
Group of artifacts used to communicate project related information to all 
stakeholders and team (status reports, status of stories etc) 
Kanban is a component of information radiator 
Ensures transparency and visibility about all the activities in the project 
Sunday 10 March 13 



Osmotic Communication 






Communication which occurs as a result of people sitting in the environment 


One team member hearing the conversation among other team members and getting 
informed is Osmotic Communication 


Osmotic communication could be useful technique for distributing culture, best 
practices and helping team members to acclimatise to the project 


On distributed/virtual teams (where team is not co-located), osmotic communication 
could be a challenge.Technology could be used to replicate colocation environment as 
much as possible. 


Drawback -Wasted time due to irrelevant communication and frequent interruptions 


Cone of Silence -Setting hours where no one allowed to talk in the co-located(war) 
room. 


Sunday 10 March 13 



Agile Tooling 






Class of tools, technologies and practices collectively is referred as Agile Tooling. 


Any technology software (High tech or Low tech) or artifacts designed to increase 
the team bonding and encourages team participation. Examples are: Collaboration 
systems,Video conferencing for virtual teams,Version control system for managing 
the codes... 


Could be used to share ideas, information, code, Knowledge, practices and 
workspace. 


Shared recreational space, daily stand-up meetings and any other activity designed to 
create sense of team belonging. 


Sunday 10 March 13 



Burn Down and Burn UP Charts Burn Down and Burn UP Charts 
Sunday 10 March 13 



Iteration Burn down Chart Iteration Burn down Chart 
Sunday 10 March 13 



KANBAN 






Japanese term -Kan (Signal) + Ban(Card/Board)==>“Signal Board” or Signal 


Cards in english 
Workflow is defined for user stories (e.g. Plan/do/check/done) and user stories 
are pulled through the system,they pull new work from prioritized backlog. 


Means through which JIT is achieved 
Pull based system 
Represents Work In Progress (WIP). Shows all WIP at one time 
One of the goal is to limit WIP 
Discourages too much work in the system at once 
Component of Information Radiator 


Sunday 10 March 13 



Basic Principles of KANBAN 


Limit work in process(WIP) 
Pull value through(with WIP limit) 
Make it visible(Visual Control) 
Increase Throughput 
Fixed KANBAN Backlog 
Quality is embedded in, not inspected in 




Sunday 10 March 13 



KANBAN KANBAN 
Sunday 10 March 13 



Cumulative Flow Diagram 






Valuable tool for tracking and forecasting 


Gives insight to project issues, cycle time and likely 
completion dates 


Part of Information radiator that shows feature 
backlogs, Work In Progress(WIP) and completed 
features over time 




Sunday 10 March 13 



Parking Lot chart 






Tool to visualize how team is doing at completing the planned 
functionality of a release 


Large Rectangular box for each theme in a release 
Each box contains name of the theme, number of stories, estimate(Story 
point or ideal days) and percentage completion. 


Powerful tool to compress great deal of information into a small space. 




Sunday 10 March 13 



Agile Estimation Agile Estimation 
Sunday 10 March 13 



Agile Estimation 






Relative Sizing 
Story Points 
Cone of Uncertainty 
Wide-band Delphi Technique 
Planning Poker 
Affinity Estimating 
Velocity 
Cycle Time 
Ideal Time 
TimeBoxing 


Sunday 10 March 13 



Relative Sizing 
Relative sizing -Rank stories by their size relative to each other. 
Estimate based on those relative ranking 
The goal is to quickly rank the user stories. Not very precise 
Relative sizing -Rank stories by their size relative to each other. 
Estimate based on those relative ranking 
The goal is to quickly rank the user stories. Not very precise 
Sunday 10 March 13 



Story Points 


Unit of measure for expressing the overall size of a user story, feature or other piece of 


work.The number of story points assigned to a story represents the overall size of story. 
Assigning point value to each story. Raw value is not important. What matters is relative 
value 


Faster estimation technique 
Story points helps cross functional behavior 
Story point estimates do not decay 
Pure measure of Size 


Sunday 10 March 13 



Cone of Uncertainty 
Accuracy of Estimate will vary over time on 
a project 
Estimates would become sharper over time 
Cone of Uncertainty 
Accuracy of Estimate will vary over time on 
a project 
Estimates would become sharper over time 
Sunday 10 March 13 



Wide-band Delphi Estimation 






Based on traditional Delphi 


Prevents groupthink to develop 


Team is given the estimation form/Card and they are brought together to discuss functionality 
or user stories. Here, no discussion on effort or estimates. After this meeting, individuals depart 
and prepare their estimates independently and share the same with facilitator. 


Facilitator lists them or plot or on a graph showing the distribution. Names of estimators are 
not given. 


Team discusses the range and tries to reach a consensus.This continues until team reaches to a 
range which is acceptable to all 


Advantage of wide-band Delphi is that team members estimates independently without any 
group pressure and at the same time wisdom and experience of entire group is taken to reach 
consensus. 


Large ranges in distribution ==> Greater risk 


Sunday 10 March 13 



Planning Poker 


Estimation technique to achieve consensus on work estimate 
Once user stories are written, planning poker can begin. 




Technical members(Developers, analyst, testers etc) of the team are brought together for this 
exercise.Works well with about 10 estimators. 


Each member is provided with deck of ten numbered cards (0,1, 3, 5, 8, 13, 20, 40 and 100.. Modified 
Fibonacci number sequence) 


Facilitator reads out the story . Each of the estimators are given time to ask questions. Once 
clarified, each estimator select a card to represents the relative level of effort for the story.The card 
is not shown to anyone at this point of time 


After everyone has selected a card, all estimators shows their card together. 


Team discussed the estimates with focus on outlier estimates (Highs and Lows).After the 
discussion, another round of estimation is done.This is repeated until broader consensus is reached 
on all the stories. 


Sunday 10 March 13 



Affinity Estimating 






Affinity Estimating-Specifically designed to address the issue of rapid 
estimating when project has huge product backlog (Lot of features) 


Team decides on some kind of ranking/grouping technique. For example, it 
cold be t-shirt sizes(S, M, L, XL,XXL,XXXL) or modified fibonacci sequence 
or it could popular coffee cup sizes (Short,Tall, Grande,Venti or Trenta) 


Finally, each user stories is read aloud and with little or no discussion, team 
places the user story within one group or sequence. 


Very Fast.Accuracy is not great. 




Sunday 10 March 13 



Velocity 






Velocity -Measure of team’s rate of progress 


Sum of story points of all completed story in one iteration. 
Uncompleted stories are not considered while measuring the velocity 


Example -In an iteration, the team has completed 3 stories with story 
points 4, 7 and 2.The team has also completed 50% of another story with 
6 story point and 90% of another story with 2 story points. What would 
be the Velocity of this iteration? So, the velocity would be 4+7 +2 = 13 
story point. 


Sunday 10 March 13 



Cycle Time 






Amount of time it takes for a feature to make it from its start to 
completion 


Start -The point where it enters the backlog and completion depends on 
team’s definition on done 


Cycle time should be start ==> Iteration should be short ==>Frequent 
small releases 


While shorter cycle time is desirable, it cannot come at the expense of 
Quality 


Sunday 10 March 13 



Ideal Time 






Ideal Time-Amount of time it would take to complete something if 
there was no interruptions, distractions or meeting. 


Assumes complete focus with all necessary resources at hand, no 
distractions and interruptions. 


This is different from Elapsed time(Calendar time) 


Example -Normal Hockey match is of 70 minutes duration. So, 70 
minutes is the ideal time. However, due to break/injuries/etc, the 
elapsed time is much more than 70 minutes. 


My ideal days are not your ideal days!!!! 


Sunday 10 March 13 



TimeBoxing 






Setting a fixed reasonable amount of time to work on features or user stories 


Helps team to focus on most important features while maintaining a sense of urgency 
and awareness of schedule 


Why TimeBoxing -An activity would take as much time as you provide (Parkinson’s 
law). So example, if you budget for an activity to take a week, it would take one 
week. However, if you trim the activity duration to 2 days, it might take only two 
days!!! 


Downside of TimeBoxing -Some activities are difficult to timebox and may result in 
wasted effort 


Sunday 10 March 13 



Planned Vs Actual Velocity Planned Vs Actual Velocity 
Sunday 10 March 13 



Agile Metrics Agile Metrics 
Sunday 10 March 13 



Agile Metrics 






Agile EarnedValue Management(EVM) 
Test Driven Development (TDD) 
Frequent Verification andValidation 
Escaped Defects 
Risk Adjusted Backlog 
Risk Burn Down chart 


Sunday 10 March 13 



Agile EarnedValue Management 






Define the initial release baseline 


Measure Progress by measuring 
Story points completed to date 
Story points added to date (Can be negative) 
Actual Cost (AC) to date 
PV(PlannedValue) = % Planned completion * BAC(Budget at Completion) 
EV(EarnedValue) = %Actual completion * BAC 
Actual Completion = Story Points completed/ Total Story points planned 
Planned Completion = Number of sprints completed/ Total number of planned sprint 
CV(Cost Variance) = EV -AC 
SV(Schedule Variance) = EV -PV 




Sunday 10 March 13 



Agile EarnedValue Management cont.. 






Example 
BAC = $200,000 
Planned sprint/Iterations = 5 
Planned story points for release = 100 
Number of sprint/iterations completed at this point of time= 2 
Story points completed at this point of time = 20 
Actual cost until now = $60,0000 
Planned completion = Number of sprint completed/Total number of sprints = 2/5 = 40% 
Actual completion = Number of story points completed/ Total story points planned = 20/100 = 20% 
EV = %Actual Completion * BAC = 20% * $200,000 = $40,000 
PV = %Planned Completion * BAC = 40% * $200,000 = $80,000 
CV = EV -AC = $40,000 -$40,000 = 0 
SV = EV -PV = $40,000 -$80,000 = -$40,000 




Sunday 10 March 13 



Test-First Development 






Create test cases first based on what are the features needed 


Customer/Product owner to define acceptance criteria ==> Translates into 
test cases 


Write your code(construct the software) so that it conforms to test 
cases(Not the other way...Make the test conforms to software) 


Ideally, these tests should have outcome of True/False 
Subjective acceptance criteria is always a problem 
When performing the tests, the software passes the test or it does 


not(Binary result:Yes or No) 


Sunday 10 March 13 



FrequentVerification andValidation 


Validation -Am I building the product right 
Ensures that product does what it was intended to do 
Verification -Am I building the right product 






Focus on ensuring that functionality meets specification 
Frequent Verification and Validation is intended to keep the project on track 
and quickly detect any deviation from value 


Sunday 10 March 13 



Escaped Defects 


Bug/Defects/Errors in the product that have been released to customer. 


These defects should have been caught during testings by developers and 
QC team. Instead, they have escaped developers and QC testing and has 
reached into customer’s hand 


Undesirable 


Important metric 


Sunday 10 March 13 



Risk Adjusted Backlog 






One of the way to mitigate risk in agile project 


Agile project should not be only business value driven but also risk driven 
as well. 


While prioritizing the product backlog, product owners should not 
overlook the risk factor 




Sunday 10 March 13 



Agile Leadership Agile Leadership 
Sunday 10 March 13 



Agile Leadership 






Brainstorming 
Active Listening 
High performance team 
Conflict Resolution 
Agile Team Stages 
Servant leadership 
Adaptive Leadership 


Sunday 10 March 13 



Brainstorming 
Brainstorming fosters creativity and involves the entire team in the process. 
Nominal group technique is enhanced form of brainstorming 
Brainstorming fosters creativity and involves the entire team in the process. 
Nominal group technique is enhanced form of brainstorming 
Sunday 10 March 13 



Active Listening 






Key steps in active listening are 
Listening 
Understanding 




Retaining 
Actively responding 
Active listening can reduce confusion and conflicts on team and can improve 
performance and results 


Sunday 10 March 13 



High Performance Team High Performance Team 
Sunday 10 March 13 



High Performance Team High Performance Team 
Sunday 10 March 13 



Agile Team Stages 




ShuHaRi 
Shu - Follow the Rule (Following)- Learner at Level 1 
Look for the procedure that works and follow that 
Ha - Break the Rule (Detaching) - Learner at Level 2 






People start looking for drawback and ways to breakdown a process 
Ri - Be the Rule (Fluent) - Learner at Level 3 
Sunday 10 March 13 



Speed Leas Framework Five Stages of Conflict Speed Leas Framework Five Stages of Conflict 
Sunday 10 March 13 



Prioritization using MoSCoW 






Originated from DSDM(Dynamic System Development Method) methodology 
Must Have -Features that must be there before product is released 
Should have -Not critical to product launch but considered important 
Could have -Nice to have features 
Won’t have -Those features which were requested but not going to be 




included in the current product release 


Sunday 10 March 13 



Servant Leadership 






Instead of top-down commanding leader, servant leader focuses on the needs of 
their team 
Co-located and Tightly integrated with team 
A person is servant first and leader second 


Participative leaders, hands on with their project and involved with team on daily 
activities 


Sunday 10 March 13 



Adaptive Leadership 






The key is -Leader adapts to his or her environment to lead efficiently and 
effectively 


Leader focuses on activities that add value 
Openness and transparency 
Works well with leaders who are more seasoned and self-aware 


Sunday 10 March 13 



Agile Contracts Agile Contracts 
Sunday 10 March 13 



Agile Contracts 
Agile Contracts 
Burn Rate 
Compliance 
Agile Contracts 
Agile Contracts 
Burn Rate 
Compliance 
Sunday 10 March 13 



Agile Contracts 






Cost responsibility -Both the parties (Target Cost Principal) 


Staged Contract -Allows to built checkpoints in contract to provide 
customer visibility and Go/No Go decision point along the way 


Sunday 10 March 13 



Burn Rate 






Amount of cost estimated over a given period of time 


Businesses always would like to know the cost and value they are going to 
receive and how much time it would take 


So, burn rate would help businesses to understand the cost. For example, if 
cost per day for agile team is $6000 and there are 5 iteration of 10 days 
each, then cost of labor associate would be = 5*10*6000 = $300000 


Sunday 10 March 13 



Organic Risk Management 






Intrinsic Schedule Flaw (estimates that are wrong and undoable from day one, 




often based on wishful thinking) 
Specification Breakdown (failure to achieve stakeholder consensus on what to 
build) 




Scope Creep (additional requirements that inflate the initially accepted set) 
Personnel Loss 


Productivity Variation (difference between assumed and actual performance) 


Sunday 10 March 13 



Agile Methodologies Agile Methodologies 
Sunday 10 March 13 



Agile Methodologies 
Introduction to Scrum 
Introduction to eXtreme Programming 
Introduction to Lean 
Brief on DSDM 
Agile Methodologies 
Introduction to Scrum 
Introduction to eXtreme Programming 
Introduction to Lean 
Brief on DSDM 
Sunday 10 March 13 



Introduction to Scrum Introduction to Scrum 
Sunday 10 March 13 



What is Scrum? 
“Scrum is a framework for developing 
complex products and systems. It is grounded 
in empirical process control theory. Scrum 
employs an iterative, incremental approach to 
optimize predictability and control risk.” 
-Ken Schwaber 
“Scrum is a framework for developing 
complex products and systems. It is grounded 
in empirical process control theory. Scrum 
employs an iterative, incremental approach to 
optimize predictability and control risk.” 
-Ken Schwaber 
Sunday 10 March 13 



What is Scrum? What is Scrum? 
Sunday 10 March 13 



What is Scrum? 
Sprint Planning 
What is Scrum? 
Sprint Planning 
Sunday 10 March 13 



What is Scrum? 
Sprint 
Daily Sprint 
What is Scrum? 
Sprint 
Daily Sprint 
Sunday 10 March 13 



What is Scrum? 
Sprint Review & Retro 
What is Scrum? 
Sprint Review & Retro 
Sunday 10 March 13 



Sunday 10 March 13 



Sunday 10 March 13 



Sunday 10 March 13 



Sunday 10 March 13 



Sunday 10 March 13 



Sunday 10 March 13 



Scrum in Nutshell 






Defined Process Control -Laying out a process that repeatably will produce acceptable 
quality output 


Empirical Process Control -When defined process control cannot be achieved because 
of the complexity of the intermediate activities 


Three legs of Empirical Process Control 




Visibility -Visibility means that those aspects of the process that affect the outcome 
must be visible(Also true) to those controlling the process. 


Inspection -The various aspects of the process must be inspected frequently enough 
that unacceptable variances in the process can be detected 


Adaptation -If the inspector determines from the inspection that one or more 
aspects of the process are outside acceptable limits and that the resulting product will 
be unacceptable, the inspector must adjust the process or the material being processed. 
The adjustment must be made as quickly as possible to minimize further deviation. 


Sunday 10 March 13 



Scrum in Nutshell 






Iterative, incremental framework 


Development in cycle of work called Sprints/Iteration, normally of 30 
days(Calendar Days) 


Sprints are done one after the another without any pause 


Sprints are Time-boxed-Specific end date. Never extended irrespective of 
whether work is complete or not. 


One of the lesser known, but valuable, guidelines in Scrum is that five or ten 
percent of each Sprint must be dedicated by the Team to refining (or 
“grooming”) the Product Backlog 


Sunday 10 March 13 



Scrum Team Values 
Commitment 
Openness 
Focus 
Courage 
Respect 
Scrum Team Values 
Commitment 
Openness 
Focus 
Courage 
Respect 
Sunday 10 March 13 



Scrum Meetings 
Planning Meeting 
Daily Stand up meeting 
Review Meeting 
Retrospective Meeting 
Scrum Meetings 
Planning Meeting 
Daily Stand up meeting 
Review Meeting 
Retrospective Meeting 
Sunday 10 March 13 



Planning Meetings 






Maximum eight hours 


Eight-hour meeting is divided into two half. 


The first half has the product owner discussing the highest priority features 
with the team.Team interacts, ask questions about the features and finally picks 
the functionality that they believe could be delivered in 30 days sprint 


In the second half, team maps out the sprint and define things down to a task 
level. Stories are placed in sprint backlog. 


Sunday 10 March 13 



Daily Stand up Meetings 






Known as Daily Scrum 
Constrained for 15 minutes each day 
Three key questions 




What work have you done since last meeting 
What are you planning to do today 
Any obstacles encountered? 


Sunday 10 March 13 



Sprint Review 






After Sprint ends, the Team and Product owner meets to review the sprint 


Often mislabeled as “Demo” but that doesn’t capture the real intent of this meeting 


Remember -Key idea in scrum is “Inspect and Adapt”. Sprint Review is nothing but 
“Inspect and Adapt” activity. It’s for Product owner to understand what is going on 
with team and product. Similarly, it is for team to understand what is going on with 
product owner and market 


The key element of this process is the “Conversation” between product owner and 
team to understand the situation and take the feedback 


Demo is part of review. However, if demo takes precedence over conversation, then 
that defies the purpose of review 


It is the responsibility of Scrum Master to ensure that everyone knows the “Definition 
of Done” for the product or release. Scrum Master prevents the team from 
demonstrating those items which are “Not done” according to “definition of done”. 
Items that are “Not done” would go back to “product backlog” for re-prioritization 


Sunday 10 March 13 



Sprint Retrospective 
Before the next 30-day sprint begins, the team meets for a sprint retrospective 
ScrumMaster works with the team to tune its own development process. 
Focus on what has worked and what needs improvement..Responsibility of the 
team because team is self organizing and self managing 
Product owner doesn’t take part in this meeting 
Before the next 30-day sprint begins, the team meets for a sprint retrospective 
ScrumMaster works with the team to tune its own development process. 
Focus on what has worked and what needs improvement..Responsibility of the 
team because team is self organizing and self managing 
Product owner doesn’t take part in this meeting 
Sunday 10 March 13 



Scrum Roles 
Scrum Master 
Team 
Product Owner 
Scrum Roles 
Scrum Master 
Team 
Product Owner 
Sunday 10 March 13 



Scrum Master 






Scrum Master is responsible for success of the project 
Helps product owner to select the product backlog and helps the team to 


turn the backlog into functionality ==> Helps to increases the chance of 
project success 
Removes the barrier between development and product owner so that 


product owner drives the development 
Keep the information of project progress up to date and visible to all 
Remove all the impediments of team 


Improve the productivity of development team in any way possible 
Responsible or ensuring that all the scrum processes are followed 




Sunday 10 March 13 



Team 






Cross-functional -Includes all the expertise to deliver the product 


Self Organizing and self Managing-Very high degree of autonomy and 
accountability 


Team is known as Pigs(Truly Committed) and all others in the organization 
are known as Chickens(Just Involved) 


Generally the team size is 7 plus/minus 2. Highly interchangeable(Generalists) 


The teams are most effective and productive if all the member are 100% 
dedicated towards one product during the sprint.(Avoid Multi-tasking). Avoid 
changing team members 


Since one team often does all the work (planning, analysis, programming, and 
testing) for a complete customer-centric feature, Teams are also known as 
feature teams. 


Sunday 10 March 13 



Product Owner 




Product Owner is responsible for 
Maximizing return on investment (ROI) by identifying product features, translating 




these into a prioritized list, deciding which should be at the top of the list for the 
next Sprint, and continually re-prioritizing and refining the list. 
Profit and loss 
Writes user stories 


Primary responsibility for product backlog(Grooming and prioritizing) 


Meets team during the first half of iteration planning meeting to discuss user 
stories 
Will work with sponsors to ensure project is adequately funded 
Effective product owner -(Committed, Responsible, Authorized, Collaborative, 


Knowledgable) -CRACK 


Sunday 10 March 13 



Scrum Steps 




Product Vision -Articulated by Product Owner 
This evolves into a refined and prioritized list of features called the 
product backlog 
This backlog exists and keep evolving through out the product life cycle. 




This is Product Road Map 


The Product Backlog includes a variety of items primarily 
New customer features 
Engineering improvement goals 
Exploratory or research work 
Known Defects 






Sunday 10 March 13 



Scrum Steps cont... 






Subset of Product Backlog intended for current release -Release Backlog 
This is the primary focus of product owner 


Product backlog is continuously updated by product owner. 
Team provides effort estimates for each item on product backlog. 
In addition, product owner is responsible for assigning “Business Value 




Estimates” to each item 
Based on these two estimates (Effort and value) and additional risk 
estimates, product owner prioritize the items in product backlog 


Common technique for estimation is in terms of relative size(Factoring in 
effort, complexity and uncertainty) using “Story Points” 


Sunday 10 March 13 



Scrum Steps cont... 
Subset of Product Backlog intended for current release -Release Backlog 
Scrum Steps cont... 
Subset of Product Backlog intended for current release -Release Backlog 
Sunday 10 March 13 



Risk-Value Relationship Risk-Value Relationship 
Sunday 10 March 13 



Difference between Release and Iteration Plan Difference between Release and Iteration Plan 
Sunday 10 March 13 



Iteration Planning 
Velocity Driven 
Commitment Driven 
Iteration Planning 
Velocity Driven 
Commitment Driven 
Sunday 10 March 13 



Velocity Driven Velocity Driven 
Sunday 10 March 13 



Commitment Driven Commitment Driven 
Sunday 10 March 13 



Kano Model of Customer Satisfaction 






Threshold or Must have Features 
Feature that must be there for product to be successful 


Linear Features 
Those features for which “the more, the better” holds true 
Customer satisfaction in linearly correlated to quantity of these 


features 
Exciter and delighters 


Those features that provide great satisfaction, often adding a price 
premium to the product 
Lack of Exciters and delighters will not decrease the customer 


satisfaction below neutral 




Often known as unknown needs 




Sunday 10 March 13 



Release Burn Down Bar Chart 
When new work is ADDED ==> Bottom of the bar is lowered 
When work is REMOVED ==> Bottom is raised 
Anytime work is completed ==> Top is lowered 
When work is reestimate ==> top moves up or down 
When new work is ADDED ==> Bottom of the bar is lowered 
When work is REMOVED ==> Bottom is raised 
Anytime work is completed ==> Top is lowered 
When work is reestimate ==> top moves up or down 
Sunday 10 March 13 



Estimating Velocity 
Use Historical Values 
Run an Iteration 
Make a Forecast 
Estimating Velocity 
Use Historical Values 
Run an Iteration 
Make a Forecast 
Sunday 10 March 13 



Introduction to eXtreme 
Programming(XP) 
Introduction to eXtreme 
Programming(XP) 
Sunday 10 March 13 



Extreme Programming 
Developed by Kent Beck 
Most disciplined agile approaches 
Seven day iteration 
Extreme Programming 
Developed by Kent Beck 
Most disciplined agile approaches 
Seven day iteration 
Sunday 10 March 13 



Extreme Programming Extreme Programming 
Sunday 10 March 13 



XP Practices 






Planning game 
Small Releases 
Metaphor 
Simple Design 
Testing 
Refactoring 
Pair Programming 
Collective Code Ownership 
Continuous Integration 
Sustainable pace 
On-Site Customer 
Coding Standards 


Sunday 10 March 13 



Refactoring 
Optimizing the source code 
Certainly one or more way to refactor the code 
Reorganization doesn’t(and shouldn’t) change the code behavior 
Optimizing the source code 
Certainly one or more way to refactor the code 
Reorganization doesn’t(and shouldn’t) change the code behavior 
Sunday 10 March 13 



Pair Programming 
Two developers working on the same code, side by side 
When executed properly within the context of XP, combined productivity 
and efficiency would go up 
Paired partners do not have to stay the same throughout the project 
Two developers working on the same code, side by side 
When executed properly within the context of XP, combined productivity 
and efficiency would go up 
Paired partners do not have to stay the same throughout the project 
Sunday 10 March 13 



Retrospectives 






Time-box your retrospective -Say for one hour 
Anyone can facilitate the retrospective 


Everyone on the team should participate in retrospectives. Non team members 
should not be allowed 


Four key steps 




Norm Kerth’s prime directive -“Regardless of what we discover today, we understand 
and truly believe that everyone did the best job they could, given what they knew at the 
time, their skills and abilities, the resources available, and the situation at hand” 


Brainstorming 
Mute Mapping 




Retrospective objective 


Sunday 10 March 13 



XP Team Values 
Communication 
Feedback 
Simplicity 
Courage 
Respect 
XP Team Values 
Communication 
Feedback 
Simplicity 
Courage 
Respect 
Sunday 10 March 13 



XP Roles 






XP Coach -Makes sure that team adheres to the XP process.Active role to 
ensure that XP principles are followed. Points out learning opportunity to 
team. Supporting role, not a top down leader 


XP Customer -Product expert. Makes sure that right product is build and 
responsible for deciding which features would deliver the greatest value. 
Participate with team in the planning game to help determine the order in 
which features should be developed.Also,determines the acceptance criteria 
and tests for the work so that team is able to determine something is 
“Done” or not. 


XP Programmer -Works in pair. One writes and other looks on to evaluate 
in the light of bigger solution. One pilots and other navigates. Backbone of 
the team. Self organizing, self managing team, that pulls user stories off the 
iteration backlogs and turn them into working software 


Sunday 10 March 13 



XP Roles cont... 






XP Tracker -Evaluates and communicates . Progress against the plan. Looks at 
various plans and plots progress against that. Posted in highly visible or public 
space. Tracks Release plan(User stories), the Iteration Plan(tasks) and the 
acceptance test. Can also keep track of other metrics which might be helpful 
in solving teams problems. Good XP tracker should be able to collect 
information without disturbing the team. 


XP Tester -Helps customer to translate the acceptance criteria into 
acceptance tests. Responsible for executing the tests and reporting the results 
to entire team 


Sunday 10 March 13 



Introduction to Lean Introduction to Lean 
Sunday 10 March 13 



Lean Principles 






Eliminate Waste 
Create Knowledge 
Build Quality in 
Decide As Late As Possible 
Deliver as fast as possible 
Empower the team 
See the Whole 


Sunday 10 March 13 



Lean Principles Lean Principles 
Sunday 10 March 13 



Eliminate Waste 






Lean is ruthless in eliminating the waste 


Waste could be in the form of Excessive meeting, documentation etc.The basic 
underlying question -Can you meet your objectives without any compromise 
on quality even without some of the steps? If answers is yes, removes those 
steps because they are waste!! Uses value stream mapping to analyze each 
activity as part of identifying the waste 


Sunday 10 March 13 



Create Knowledge (Amplify Learning) 
Continuous learning and improvement by shorter iterations 
Processes are constantly adapted to make them more efficient and effective. 
Brief experiments are encouraged to discover the best way to accomplish 
something(Spikes) 
Continuous learning and improvement by shorter iterations 
Processes are constantly adapted to make them more efficient and effective. 
Brief experiments are encouraged to discover the best way to accomplish 
something(Spikes) 
Sunday 10 March 13 



Decide as late as possible 


Although decisions commits us to paths, agile(and lean )embraces being 
adaptive to change 


Pushing the decision as far as possible into future, lean keeps more options 
which improves the quality 


Sunday 10 March 13 



Deliver as fast as possible 
Deliver the functionality into customer’s hand as fast as possible with the 
goal of getting the feedback from customer for further implementations. 
Deliver the functionality into customer’s hand as fast as possible with the 
goal of getting the feedback from customer for further implementations. 
Sunday 10 March 13 



Empower the team 
Team is empowered to make decisions and entire team is accountable for 
these decisions 
Empower the team 
Team is empowered to make decisions and entire team is accountable for 
these decisions 
Sunday 10 March 13 



See the Whole 
The solution created by team should look and feel like one whole solution, not 
7 different solution glued together. Seeing the whole also requires the team to 
understand how the solution is being marketed and the need for project 
existence. 
The solution created by team should look and feel like one whole solution, not 
7 different solution glued together. Seeing the whole also requires the team to 
understand how the solution is being marketed and the need for project 
existence. 
Sunday 10 March 13 



Brief on DSDM Brief on DSDM 
Sunday 10 March 13 



DSDM 






Dynamic Systems and Development Methods 
Fixes Cost, Quality and Time at the outset and uses MoSCoW prioritization 
An extension of RAD (Rapid Application Development) 
Eight principals behind DSDM 




Focus on Business need 
Deliver on Time 
Collaborate 
Never compromise on quality 
Build Incrementally with firm foundation 
Develop Iteratively 
Communicate continuously and clearly 
Demonstrate Control 




Sunday 10 March 13 



Reference 
Agile Project Management with Scrum -Ken Schwaber 
The Software Project Manager's Bridge to Agility -Michele Sliger, Stacia Broderick 
User Stories Applied: For Agile Software Development -Mike Cohn 
Agile Estimating and Planning -Mike Cohn 
The are of Agile Development -James Shore and Shane Warden 
Agile Project Management with Scrum -Ken Schwaber 
The Software Project Manager's Bridge to Agility -Michele Sliger, Stacia Broderick 
User Stories Applied: For Agile Software Development -Mike Cohn 
Agile Estimating and Planning -Mike Cohn 
The are of Agile Development -James Shore and Shane Warden 
Sunday 10 March 13 



Any Questions Any Questions 
Sunday 10 March 13