Contenu connexe
Similaire à ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile
Similaire à ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile (20)
Plus de India Scrum Enthusiasts Community
Plus de India Scrum Enthusiasts Community (20)
ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile
- 1. Effective requirement management
in distributed Agile environment
Harshawardhan Pandit
Anand Dudhmande
Mahesh Sidhanti
© 2011 Persistent Systems Ltd
www.persistentsys.com
1
- 2. Presentation Team
• Harshawardhan Pandit,
•
•
•
•
•
•
PMP, CSM
Project Manager in Persistent Systems Ltd.
Agile enthusiast
Actively working in Agile projects in various roles since 2005
Active in Scrum Master role since 2008
Has handled some nasty escalations in Agile projects
Has been part of a failure Agile project (along with some successful ones)
• Other People involved
• Mahesh Sidhanti- Process Manager, Delivery Excellence- Persistent Systems Ltd.
• Anand Dudhmande- Process Manager, Delivery Excellence- Persistent Systems Ltd.
© 2011 Persistent Systems Ltd
www.persistentsys.com
2
- 3. Common challenges in Agile projects:
Sounds familiar?
Offshore team
velocity is not as good
as US counter part!!!
All the committed
user stories not
completed by the
team…!
Defect leakages
in offshore team
deliverables
Ineffective requirement
management of user
stories? One probable cause
Cant trust
offshore team for
their
commitments!
© 2011 Persistent Systems Ltd
Is offshore team
matured enough to
deliver complex
functionalities?
www.persistentsys.com
3
- 4. Problem statement
1. More number of rolled over
user stories
2. Defect leakages in deliverables
© 2011 Persistent Systems Ltd
1. Customer dissatisfaction
2. Customer revenue
3. Team demotivation
www.persistentsys.com
4
- 5. Fishbone Diagram for user story rollovers
Wrong Estimations
Dependencies
Ineffective reviews
Waiting for clarifications
Not enough detailing
3rd Party S/W libraries
Misplaced Optimism
inexperience
Misunderstanding of scope
interdependencies on
other user stories
User Story
Rollover
Partial requirements by PO
Misunderstanding of
scope
Insufficient Product
Knowledge & Exp.
Impatience,
Hasty Start
Insufficient Analysis
© 2011 Persistent Systems Ltd
Incomplete
Product Backlog
Pleasing Client
Peer Pressure
Over commitment
Impact due to design
changes mid sprint
Evolving Product Specs
www.persistentsys.com
5
- 6. Fishbone Diagram for typical cases of defect leakage
Insufficient QA Analysis due to
misunderstood requirements
Misunderstanding of
requirements by QA
Insufficient Impact analysis
Requirements not analyzed &
understood properly for impact on
existing functionality
Misunderstanding of
the scope of testing
Lack of depth of
knowledge of existing
functionality
New functionality
broke the existing
functionality
Some test cases
were ignored
Defect Leakage
in release
No formal confirmation
on the implied
requirements
Non-Elaboration of
Implied Requirements
Process slippage for the
requirements
© 2011 Persistent Systems Ltd
Some
requirements were
missed for
implementation
Non-Elaboration of
Implied Requirements
Improper/ Insufficient
Requirement Understanding
www.persistentsys.com
6
- 7. FMEA performed on the sample
FMEA for Rolled Over User Stories [RPN]
FMEA for Defect Leakage
[RPN]
Misunderstanding of scope
210
Misunderstanding of the scope of testing
240
In-effective reviews during requirement
detailing
144
Requirements not analyzed for impact on
existing functionality
175
Not enough detailing by team
140
Misunderstanding of requirements by QA
160
Partial requirements from PO
140
Some test cases were ignored
144
Waiting for clarifications
125
Some requirements were missed
125
Impatient/Hasty start
120
New functionality broke the existing
functionality
96
Misplaced optimism
100
No formal confirmation on the implied
requirements
75
Interdependencies on other user stories
90
Non elaboration of the implied
requirements
75
3rd Party Software and Libraries
90
Peer pressure
64
Need to please customer
64
© 2011 Persistent Systems Ltd
www.persistentsys.com
7
- 8. Analysis of a sample data for Agile projects
A data sample focusing on selected Agile projects:
1
Average % completion of the user stories
89%
2
Average % of roll over due to external factors
6%
3
Average % rolled over of the user stories due to requirement management
failure
5%
1
Average % time of the sprint required to complete the requirement
freezing/detailing
25%
© 2011 Persistent Systems Ltd
www.persistentsys.com
8
- 9. SIPOC
Sprint Planning
Supplier
•
Input
Product Manager •
(Customer)
•
•
User Stories
Business value
Rankings
Process
•
•
•
•
•
Output
Prioritization
•
Rightsizing/Cross check •
for right sizing
Estimation in story points
(Fibonacci series)
Review/Validation by
Scrum master
Functional clarifications
Customer
Committed list of user stories. •
Sprint plan (Estimates,
ownership)
•
•
•
Product Manager
(Customer)
Scrum Master
Team Lead
Developers
Requirement Analysis/Detailing Phase
Supplier
• Scrum Master
• Team Lead
Input
Process
• For Each User Story • Decision making*
(Splitting of user stories)
• Designing & Detailing
• Impact Analysis
• QA Detailing.
• Refining
estimates/schedule.
© 2011 Persistent Systems Ltd
Output
Customer
• Multiple /Split user stories*
• Understanding
document/Requirement
detailing/ User story detailing
• Refined Acceptance Criteria
• Refined Estimates
• Refined Schedule
• Product Manager
(Customer).
• Scrum Master
• Team
Lead/Developers
www.persistentsys.com
9
- 10. Boundaries for the required solution
(Considering Agile principles)
Should not ask for heavy • Should focus on quick/effective communication
with stakeholders
documentation
Work with-in Agile
framework
• Should be embedded into Agile
ceremonies/events
Focus on the continuous • Help teams develop the right discipline & build
maturity in each iteration
improvement
Focus on principle of
‘cross -functional
working teams’
© 2011 Persistent Systems Ltd
• Aim at teams collaborating for a common cause
• Aim at building knowledge across team members
www.persistentsys.com
10
- 11. Lifecycle of a typical Agile project
© 2011 Persistent Systems Ltd
www.persistentsys.com
11
- 12. Challenges in following Best Practices of Agile
- And proposed workarounds
Best Practices
(being followed)
Some form of Backlog grooming
Use Sprint planning for
acceptance criteria refinement
Challenges
PO not in same time zone
hence, not able to resolve queries
right away
Typical pyramid with junior /less
experienced team members.
Zero or little domain expertise
Overcoming
Challenges
1. Process guidelines for collaborative
analysis of requirements during
sprint planning
2. Process guidelines for effective
understanding of requirements
3. Process guidelines for effective
email communication
1. Understanding Documents
Splitting large User Stories as
much as possible
Acceptance Criteria not clear to
the team
2. Impact Checklists
3. E-mail Communication
Templates
Focus is in inculcating right discipline
and habits (NOT to add
documentation). The documentation
can fade away as the team matures.
© 2011 Persistent Systems Ltd
www.persistentsys.com
12
- 13. Process Improvements in the Agile Process
Daily scrum meeting (24 h)
Sprint Planning (Day 1)
•
•
•
Backlog tasks expanded
by team with
collaborative analysis
Use of understanding
documents
Use of standard Email
templates
Sprint backlog
Sprint duration (10-20 days)
Demonstrate new
functionality
• Technical Implementation document
template to detail out the implementation
approach
• Use of standard email templates
Backlog grooming
phase(Sprint start -2 days)
Product backlog as
prioritized by product
owner
© 2011 Persistent Systems Ltd
Indicates suggested
process area and
recommendations
www.persistentsys.com
13
- 14. Process Improvements and Optimizations
Impact
Analysis
Checklist
Collaborative
Analysis
Effective
Communication
Requirement
Detailing
1)
2)
3)
4)
Sample
templates for
effective email
communication
Email Template
Understanding
Document
template
Understanding
Document
Template
Why document when Agile discourages ‘lengthy
documentation’.
What and how to document?
How much time to spend?
By Whom?
© 2011 Persistent Systems Ltd
Impact checklist
during
collaborative
analysis
1)
2)
3)
Implementation
Document
template
Separate out the ‘functional detailing’ and
‘implementation detailing’.
Make the functional detailing time boxed.
Standardized email templates for
communication with PO and onsite tech leads.
www.persistentsys.com
14
- 15. Suggested process Optimizations /Improvements
Exhaustive Impact Analysis Checklist (Tool)
Better Collaborative first level analysis (Process)
Effective Tele-con with Product Managers (Process)
Separate Functional detailing vs Implementation
detailing
Updated
understanding
document
(Acceptance criteria)
Effective Developer - QA collaboration (Process)
Standardized Email templates (Tool)
© 2011 Persistent Systems Ltd
www.persistentsys.com
15
- 16. Process Optimizations- Explained
Impact Analysis Checklist
• It was found that there was no standard and formal way to do impact analysis on a user story. A generic
template was designed to cover most of the areas and provision for adding more impact areas based on the
product was made. The checklist is now used as a entry point while performing requirement analysis on a
user story.
Collaborative first level analysis
• To aid to above (Impact analysis), the complete team is involved during the first level analysis to catch any
possible impact areas which might not be caught by a sole developer.
Tele-con with Product Managers
• To help get the feedback on the queries it is proposed to have telecon with the technical lead or the
product manager at client side during the Requirement gathering phase so that with each progressive day
some user stories get cleaned , approved and get to a ready for development stage.
Developer and QA collaboration
• It was strongly proposed to have the developer and the QA closely work right from the beginning of the
user story, while they create the understanding document to facilitate addressing of any misunderstandings
and identifying untouched impact areas for a user story.
Standardized email templates
• A standard email template was proposed to be used to send queries against a user story to client. This is to
bring uniformity in how the folks communicate and also touch base all the important areas while the query
is written.
© 2011 Persistent Systems Ltd
www.persistentsys.com
16
- 17. Outcome of the process optimizations
• Understanding
Document
• Technical
Implementation
document
• Impact Analysis
checklist
• Defect leakage brought
under control
• Reduced number of
rollover user stories
• Quicker start time
• Standard Email
templates for
asking queries
Process Changes
© 2011 Persistent Systems Ltd
www.persistentsys.com
17
- 18. Results…
Updated results on the same sample
Historical
New
93%
1
Average % completion of the user stories
89%
2
Average % of roll over due to external factors
6%
3
Average % rolled over of the user stories due to requirement
management failure
5%
=>
1%
1
Average % time of the sprint required to complete the requirement
freezing/detailing
25%
=>
20%
© 2011 Persistent Systems Ltd
=>
6%
www.persistentsys.com
18