• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile
 

ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile

on

  • 212 views

 

Statistics

Views

Total Views
212
Views on SlideShare
212
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile ATC2013-Harshawardhan- Effective requirement management-in_distributed_agile Presentation Transcript

    • Effective requirement management in distributed Agile environment Harshawardhan Pandit Anand Dudhmande Mahesh Sidhanti © 2011 Persistent Systems Ltd www.persistentsys.com 1
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Lifecycle of a typical Agile project © 2011 Persistent Systems Ltd www.persistentsys.com 11
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Thank You www.persistentsys.com