Agile Techniques
- 1. P K Mallik Approach, Techniques and Tools Agile Techniques
- 2. P K Mallik • Objectives • Key Benefits • Key Concepts • User Stories • Estimation • Planning • Techniques • Tools • Models • Guidelines Agile Techniques
- 3. P K Mallik Objectives • Create clear business value across stakeholders • Improve predictability of project and product delivery • Create environment where deviations are the exception
- 4. 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
- 5. P K Mallik Key Concepts Term Description Example Epic A very large user story, needs to be split into smaller stories to fit the iterations Member 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 points Member registration 14 story points Purchase 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 access Iteration 2 : Member Registration Contact Details Iteration 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
- 6. 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
- 7. 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?
- 8. P K Mallik Myths 1. No Documentation Documentation is required. Current artefacts will continue to be produced Main changes are in Project, Release and Iteration (Sprint) plan 2. No QMS QMS is very much applicable Only planning process is different Existing Processes & Templates will apply for deliverables 3. No Dashboard Agile metrics can be mapped to dashboard Metrics calculations are somewhat different from current formulae Dashboard can be generated with equivalent numbers 4. No ePMO Agile tools will maintain project related data Data import feasibility is being worked out Once completed ePMO reports can be generated using imported data
- 9. P K Mallik Epic, Feature, Sub Feature, Story, TasksEpicStory 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)
- 10. 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
- 11. 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>
- 12. 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)
- 13. 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.
- 14. 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
- 15. 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 UserStories 1 2 3 5 PlanningPoker User Story Size Estimates Convergence Discuss High Low Estimates NoEnd Yes SizingBuckets 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
- 16. P K Mallik Estimating by Relative Complexity Story/Epic/Theme Parents Epic/Theme Baseline Relative Complexity Story Points Baseline Quote Creation NA 179 Individual Information Capture Quote Creation Individual Information Capture 1 12 Individual Information Capture Individual Information Update Quote Creation Individual Information Capture 0.5 6 Individual Information Capture Single state policy processing Quote Creation Individual Information Capture 2 24 Support different policy terms Quote Creation Single state policy processing 0.75 18 Agent business support Quote Creation Single state policy processing 1.5 36 Insured as a Common entity Quote Creation Single state policy processing 0.5 12 Insured as a Private entity Quote Creation Insured as a Common entity 0.75 9
- 17. 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
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. P K Mallik Agile Techniques
- 23. 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
- 24. 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
- 25. 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 Meeting 14-30 day Sprints Develop Adjust Wrap Review
- 26. 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.
- 27. 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.
- 28. 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.
- 29. 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
- 30. 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 Ready Task 3 User Story 2 Task 1 Task 3 Task Board 5 3 7 4 2 6 2 Task 4 5 Task 2 2 19 10 AR ST PP LR Task 1
- 31. 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
- 32. 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.
- 33. P K Mallik Source : http://www.agiledata.org/essays/tdd.html Test Driven Development (TDD)
- 34. 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.
- 35. 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
- 36. 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.
- 37. 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 StoryPoints 1 32 54 6 -20 0 40 80 Iterations StoryPoints 20 60 Points Added Points Removed Velocity Theme 1 12 Stories 51 story points 50%
- 38. 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
- 39. 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
- 40. P K Mallik Agile Tool – Release Level Plan & Review Issues include User Stories, Tasks, Bugs Scope of Sprint
- 41. 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
- 42. P K Mallik Agile Detailed – Tracking
- 43. P K Mallik Release Tracking – Burndown (post Iteration) 20 Based on current velocity, team is expected to complete 368 – 20 = 348 story points Snapshot at Release 1 - Sprint 2 completion
- 44. 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
- 45. P K Mallik Agile Delivery Model Business Case Application Release Sprint Factory Acceptance User Acceptance System Integration Deployment ValueRealisation Functional Tactical Strategic Business
- 46. P K Mallik Agile Coverage Level 0 – Start up Level 1 – Basic Level 2 – Advanced Level 3 – Enterprise BusinessFunctionalTacticalStrategic BusinessValue
- 47. 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 ReleasePlan Delivery – Development and Testing DetailedDesign/FnSpec Delivery – Acceptance UAT Iteration Plan Coding and UT Module Integration Testing Task Assignment HLD Templates Standards Common Components Entities Attributes and Relations Code Configuration NFR Testing Walkthrough Production Feature Sizing Acceptance Test Plan
- 48. P K Mallik ` ` Iteration Agile Plan for Projects Application Backlog • Requirement Backlog • Change Requests/Enhancements • Defects PrioritiseUser Stories Release Release Backlog Iteration 1 Iteration 2 Iteration 3 Iteration 4 Task 1 Task 2 Task 3 Build Test Detailed Design High Level Design Acceptance Criteria Test Plan Non Functional Test Plan Non Functional Test Rework Delivery Packaging Installation UAT NFR Testing SIT Detailed Requirement High Level Reqmnt
- 49. P K Mallik Offshore Onsite Onsite Project Life Cycle Scope (Epics/Themes) Solution Architecture Release Plan Iteration Plan Low Level Design Code Unit Testing Module Integration Testing NFR Testing Acceptance Test Plan Factory Acceptance Testing System integration Testing User Stories Release Backlog Requirements Overview Sizing and Effort Release Iteration Application/Product Standards 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
- 50. 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
- 51. 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 ReleasePlan Delivery – Development and Testing GapDetails/DataMapping Delivery – Acceptance UAT Iteration Plan Coding and UT Data Migration Task Assignment Bespoke Components Gap Identification Defects List Acceptance Test Plan Code Configuration NFR Testing Walkthrough Production Demonstration Configuration and Merging NFR Testing
- 52. P K Mallik ` ` ` Iteration Product Implementation Plan Application Backlog • Requirement Backlog • Enhancements • Defects Prioritise Features Enhancements Defects Release Release Backlog Iteration 1 Iteration 2 Iteration 3 Iteration 4 Task 1 Task 2 Task 3 Gap Detailing Test Configure and Demonstrate Configuration and Demo Migration Plan Build and Reconfigure Non Functional Test Plan Non Functional Test Rework Gap Analysis Delivery Installation Configuration Merging UAT SITMigrate Data
- 53. P K Mallik Offshore Onsite Onsite Product Implementation Life Cycle Scope (Features and Gaps) Base Installation Release Plan Unit Testing Module Integration Testing NFR Testing Factory Acceptance Testing Integration Testing Features/Gaps/Defects Identify Gaps Sizing and Effort Release Iteration Product BA Product Owner Developer Tester Project Manager Gap Estimate TA Configuration NFR TestingSystem Integration Testing Data Migration UAT Manage Base Defects Migrate Data Iteration Plan Code Acceptance Test Plan User Stories (features and gaps)/Defects Base Changes/Fixes Gap Detailing Design Demo (Model Office) Base Configuration
- 54. P K Mallik Features Enhancements Defects Model Product Implementation Plan Release 2 Implementation FAT Iteration 1 Design Build Test Base Installation NFR Base Configuration Demo Design Build TestDemo Iteration 2 Config Build TestDesign Iteration 3 Release 1 Implementation FAT Iteration 1 Design Build Test NFR Demo Iteration 1 Design Build TestDemo Iteration 1 Design 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 Analysis Configuration 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
- 55. P K Mallik Agile Guidelines 1. The whole team should be involved in planning and estimation even though primary responsibility for some activities fall on individuals 2. Planning must be done at different levels (release, iteration and daily) with higher levels of precision 3. Estimates of size and duration must be kept separate 4. Plans must express uncertainty in either functionality or dates depending upon whether duration or functionality is fixed 5. Re-plan at the start of each iteration to assess the relevance of the release plan 6. Track and communicate progress to all stakeholders 7. Understand that a project is as much about generating new knowledge as about adding new capabilities to the product 8. 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 possible 10. Base estimates and plans on facts (real observer values) 11. Plan some slack for team members availability, utilisation and productivity 12. Co-ordinate across teams through look-ahead planning in projects with multiple teams
- 56. P K Mallik Thank You