ProposedWorkflow_IntegrationProjects_18Jan23 (1).pptx

Guidelines for Agile integration projects

1. Proposed workflow for Agile Integration projects

2. 16/8/2022 A g e n d a S r . N o Topics 1 Assumptions 2 SAFE workflow 3 Proposed Workflow 3 ART Cadence 4 Inputs and Outputs of Project planning 5 Schedule/Status 6 Risks : For the Upcoming milestones 7 Open Items 8 India holiday list

3. 1/18/2023 Assumptions All inputs required for current sprint are available. Product backlog is defined properly. Resources are in-lined with the project (Trainings). Scope of current milestone is clearly understood. All dependencies are resolved Team is properly skilled Team is willing to embrace agile. Team is scrum and agile trained.

4. Scaled Agile ART cycle 1 2 / 1 4 / 2 2 2 Theproposedplanis basedonSAFEandAgile methodology,butitis customizedfor integrationproject.

5. 1 2 / 1 4 / 2 2 2 M i l e s t on e Planning M i l e s t on e 1 S p r i n t S p r i n t 1 S p r i n t N PI P l a n n i n g #1 PI P l a n n i n g #2 PI P l a n n i n g #n Suggested workflow for Integration Team Features User story O u t pu t s E p i c s M i l e s t on e 2 S p r i n t 1 S p r i n t N Kick off Only during start of the project.

6. Program Increment (PI) Cadence Sprint planning Sprint Review Sprint Retrospective Backlog Grooming Mid Sprint Review Product Backlog Refinement PI planning PI planning WK1 WK2 WK3 WK4 WK5 WK6 WK7 WK8 WK9 W K 10 WK11 W K 12 PI 1 PI 2 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 System Demo 1/18/2023

7. Cadence Week Week 1 Week 2 Week 3 Week 4 Week 5 Saturday & Sunday Monday Sprint P l a n n i ng Backlog r e f i n e me nt Sprint P l a n n i ng Backlog r e f i n eme nt Sprint P l a n n i ng Tuesday Wednesday Thursday PI Planning and Backlog Updation Backlog gro o m i ng Mid Sprint Review Friday Sprint Backlog G r o o m i n g Mid Sprint R e v i e w Sprint Review and R e tro s p e c t ive Mid Sprint Review Sprint Review and R e tro s p e c t i ve 1/18/2023

8. Cadence 1/18/2023 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Saturday & Sunday Monday Sprint P l a n n i ng Backlog r e f i n e me nt Sprint P l a n n i ng Backlog r e f i n eme nt Sprint P l a n n i ng Tuesday Wednesday Backlog r e f i n e m e nt Thursday Backlog gr o o m i ng Backlog gro o m i ng Mid Sprint Review Friday Sprint Review and R e tro s p e c t i v e Mid Sprint R e v i e w Sprint Review and R e tro s p e c t ive Mid Sprint Review Sprint Review and R e tro s p e c t i ve

9. Cadence Week 12 Week 13 Week 14 Week 15 Week 16 Week 17 Saturday & Sunday Monday Sprint P l a n n i ng Backlog r e f i n e m e nt Sprint P l a n n i ng Backlog r e f i n e me nt Sprint P l a n n i ng Tuesday Wednesday Backlog refinement & PI Refinement Thursday Backlog grooming & PI Planning Backlog gr o o m i ng Mid Sprint R e v i e w Friday Sprint Review and R e tro s p e c t i ve and System Demo Mid Sprint Review Sprint Review and R e tro s p e c t i ve Mid Sprint Review Sprint Review and R e tro s p e c t i ve 1/18/2023

10. Cadence: With Egypt resources Week Week 1 Week 2 Week 3 Week 4 Week 5 Saturday & Sunday Monday Sprint P l a n n i ng Backlog r e f i n e me nt Sprint P l a n n i ng Backlog r e f i n eme nt Sprint P l a n n i ng Tuesday Wednesday PI Planning and Backlog Updation Backlog gro o m i ng Backlog gro o m i ng Thursday Sprint Backlog G r o o m i n g Mid Sprint R e v i e w Sprint Review and R e tro s p e c t i ve Mid Sprint R e v i e w Sprint Review and R e tro s p e c t i ve Mid Sprint Review Friday 1/18/2023

11. Cadence: With Egypt resources 1/18/2023 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Saturday & Sunday Monday Sprint P l a n n i ng Backlog r e f i n e me nt Sprint P l a n n i ng Backlog r e f i n eme nt Sprint P l a n n i ng Tuesday Wednesday Backlog Upd a t i o n Backlog gro o m i ng Backlog gro o m i ng Thursday Sprint Backlog G r o o m i n g Mid Sprint R e v i e w Sprint Review and R e tro s p e c t i ve Mid Sprint R e v i e w Sprint Review and R e tro s p e c t i ve Mid Sprint Review Friday

12. Cadence: With Egypt resources Week 12 Week 13 Week 14 Week 15 Week 16 Week 17 Saturday & Sunday Monday Sprint P l a n n i ng Backlog r e f i n e me nt Sprint P l a n n i ng Backlog r e f i n eme nt Sprint P l a n n i ng Tuesday PI Refinement Wednesday PI Planning and Backlog Updation Backlog gro o m i ng Backlog gro o m i ng Thursday Sprint Backlog Grooming & System Demo Mid Sprint R e v i e w Sprint Review and R e tro s p e c t i ve Mid Sprint R e v i e w Sprint Review and R e tro s p e c t i ve Mid Sprint Review Friday 1/18/2023

13. Sprint Cadence 1/18/2023

14. Events 1 4 The What The Who The Inputs The Outputs The How Properties

15. PI Planning 1/18/2023 15 The What: To update product backlog in alignment with the milestone goals and customer expectation The Who: Attended by : PO/SME, SM, Project Manager, Tech Lead, Managers and Stake holders Facilitator: PO/RTE The Inputs: Business Context Product/Solution Vision Current Product Team Capacity Internal available software and technologies External available software and technologies Architecture vision and development practices P r o p e r t i e s : The Outputs: Program Board/Milestone Updated Product backlog Risks The How: Events in PI planning Draft plan on Program Board Technical Review Management Review Final Plan on Program board Risk Assessment Output oriented. Aligns with milestone goals and priorities Epic and user story creation from features PO monitors each story properly

16. Sprint Planning 1/18/2023 16 The What: The product owner describes the objective(or goal) of the sprint and what backlog items contribute to that goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen. The Who: Attended by : PO, Development Team, SM, Customer and Other stakeholders The development team plans the work necessary to deliver the sprint goal. Ultimately, the resulting sprint plan is a negotiation between the development team and product owner based on value and effort. The Inputs: Product Backlog The Outputs: Sprint Goal/Sprint backlog The How: Team selects items from the product backlog they can commit to completing Tasks are identified and each is estimated (1-16 hours) Properties: T i m e bo x e d ( 3 m i n t o 1 h r . ) Output oriented. Aligns with milestone goals and priorities Prioritized user stories are created Conducted in the start of sprint PO monitors each story properly DT commits to the estimated time. SM ensures time box and user story description is ensured.

17. Daily Scrum Meeting/ Daily Stand-ups 1/18/2023 17 The What: Team Huddle Teams joins to keep everyone aware of the team’s landscape and progress. The Who: Attended by: Development Team, SM, PO, Customer, Other stake-holders SM conducts it to get status of the team The Inputs: Sprint board The Outputs: Updated Sprint board The How: Each team member explains What was done yesterday What is planned for today? Any Blocker? SM helps by fixing meetings for blocker resolution if required Properties: Time boxed (10 to 15 mins) Follows pattern Aligns with priorities set in the Sprint backlogs. Conducted daily No discussion !!!!

18. Sprint Review The How: For each user story Status What was accomplished Stake holder’s feedback Issues Properties: NOT Retrospective Time boxed (30 to 180 mins) as per sprint duration Conducted at the end of the sprint Product backlog is in line with the milestone goals. Directed and Facilitated Discussions !!! 1/18/2023 18 The What: A sprint review is about demonstrating the hard work of the entire team: designers, developers, and the product owner. The Who: Attended by: Development Team, SM, PO, Customer, Other stake-holders The team shows what was accomplished, while the stakeholders provide feedback in a collaborative manner The Inputs: Sprint goal/Sprint backlogs, Potential release The Outputs: Updated Product backlog

19. Sprint Retrospective The How: Each member tells What went right What went wrong Learnings What could be improved How it can be improved Any Framework improvement Properties: Not strictly Time boxed (30 to 180 mins) as per sprint duration Conducted at the end of the sprint Last activity of sprint Directed and Facilitated Discussions !!! 1/18/2023 • Tangible improvements in sprint 19 The What: The sprint retrospective is a recurring meeting used to discuss what went well during the previous sprint cycle and what can be improved for the next sprint. The Who: Attended by: Development Team, SM, PO, Customer, Other stake-holders The team shows what was accomplished, while the stakeholders provide feedback in a collaborative manner The Inputs: Sprint backlogs, Product backlog The Outputs:

20. Product Backlog Refinement 1/18/2023 20 • Updated Product backlog The What: In product backlog refinement details are added to each user story of product backlog. The Who: Attended by: PO, SM, Lead engineers, Development team, Customer, Other stake- holders PO conducts it with the Development Team to collaborate on the details of Product Backlog items. The Inputs: Product backlog The Outputs: The How: For each user story Estimates is done. Alignment with milestones is done Details are added Timeboxing is done Properties: NOT Sprint planning Not strictly Time boxed (30 to 180 mins) as per sprint duration Conducted before sprint planning Directed and Facilitated Discussions !!!

21. Product Backlog Grooming The What: The primary purpose of a backlog grooming session is to ensure the next few sprints worth of user stories in the product backlog are prepared for sprint planning. The Who: Attended by: PO, SM, Lead engineers, Development team, Customer, Other stake- holders PO conducts it with the Development Team to collaborate on the details of Product Backlog items. The Inputs: 1/18/2023 21 • Product backlog The Outputs: Updated Product backlog The How: For each user story User story Estimates is done. User story description is updated. Timeboxing is done User story prioritization is done. Properties: NOT Sprint planning Not strictly Time boxed (30 to 180 mins) as per sprint duration Conducted before sprint planning Prioritization of user story

22. Increases Team Efficiency Helps Teams push forward continuously & increase overall efficiency. Helps handle tasks more efficiently, establish what we should be working, gives clear directions regarding what work needs to be done next and when eve r y o n e Benefits of Backlog Grooming 1/18/2023 22 Manages Backlog Mess Backlog is constantly updated by Product Manager, Tester, Developer which can cause a messy and chaotic backlog with many outdates items. It’s process of selecting which tasks are most relevant to work on next Keeps The Product Team Up-To-Date Everyone stay informed about the status of different features and other aspects of the project at any given time. Ensures transparency among members, no need to re-explai the tasks because everyone already knows upfront, the more productive the work Increases work velocity Helps not get overwhelmed by the number of incomplete tasks. Forces teams to deliver the product more rapidly, ensures the organization is moving forward on schedule. Reduces time spent on planning sprints, increases the productivity of

23. Make your Product Backlog DEEP- detailed, Estimated, Emergent & Prioritized 1 Have Better Meetings 2 Keep Customers in Mind 3 Identify Dependencies 4 Have Two-Three Sprints worth of Stories to work on 5 6 10 Backlog Grooming Best Practices You Must Know 1/18/2023 23 Be Professional 7 Determine the shared Qualities Across All Backlog Items (Description, Value, Order and Estimate) 8 Categorize Backlog Items for a Better Arrangement (User Stories, Feature Specifications, Feature Requests, Bugs, User insights and Feedback) 9 Come Equipped to Backlog Grooming Sessions 1 L i s t e n

24. Backlog Grooming Checklist Does the Backlog contain outdated user stories? Does your Customer expect you to carry out any urgent items that’s at the bottom of the backlog? Did a critical item change since you last booked at the backlog? Does the backlog have any item for which no agile estimate exists? Are there any outdated estimates? Is any backlog item too comprehensive to understand? 24 During any sprint-> Spike can be added although its not recommended.

25. PI Backlog Refinement The What: To consider upcoming features that are planned to be delivered in ART. The Who: Attended by: PO, SM, Lead engineers, Development team, Customer, Other stake- holders PO conducts it with the Development Team to collaborate on the details of Product Backlog items. The Inputs: Product backlog The Outputs: Updated Product backlog 1/18/2023 2 5 The How: Each feature is broken down into epics which are broken into user stories Each user story is tentatively planned into upcoming sprint. Each user story is added with as much detail as possible Properties: NOT Sprint planning Not strictly Time boxed (30 to 180 mins) as per sprint duration Conducted before sprint planning Prioritization of user story

26. System Demo 1/18/2023 The What: An event to provides an integrated view of new Features for the most recent sprint. The Who: Attended by: SM, Lead engineers, Development team, Customer, Other stake- holders, RTE RTE conducts it with the Development Team to collaborate on the details of Product Backlog items. The Inputs: PI Backlog Outputs are in proper place to deliver to customer as per CM. The Outputs: Updated PI backlog The How: Running Product demo is given that has been developed so far. Each PI from PO Backlog is selected For each PI objective, the acceptance criteria is matched to achieved objectives Customer Feedback Accordingly, the PI backlog is updated. Properties: NOT Sprint Review Strictly Time boxed (60 to 90 mins) as per sprint duration Priortization is done.

27. Implementation Units 2 7 Features Epics User stories Tasks

28. Hierarchy 1/18/2023 28 Ta s k s

29. Epic Vs Features Vs User story Vs Task 1/18/2023 29 large b o d i e s of work that can be broken down into a number of smaller ITEMS. It cannot be achieved in single sprint Broad in scope Based on definition of minimum viable product User stories are short requirements o r requests written from the customer p e r s p e c t i v e . Its what user wants Only created for single sprint They can be Enabler Requirement Small complete feature T a s k s User stories are broken into tasks. Tasks are workable solutions of a user story. Task are deliverable solution of work Tasks can range from a few hours to whole Day Suggestion- Create task for a day. SMALLEST UNIT of work Assigned only to one resource Epics Feature User stories E p i c s a r e • A feature is a service or function of the product that d e l i v e r s business value and fulfils the customer’s need. Each feature is broken down into several user stories, as it is usually too big to be worked on directly. Big enough to be released

30. E p i c s 1/18/2023 30 What is an Epic? NOT PROJECTS An actualization of product workmap Epic Structure Introduction Why What Product requirements Design requirements Where to find prototype Where to find inputs Engineering requirements High level architecture High level estimations KPI metrics Set of metrics Set of goals

31. User Story 1/18/2023 31 What is User story? It’s an end goal, not a feature, expressed from the software user’s perspective. an informal, general explanation of a software feature written from the perspective of the end user or customer articulate how a piece of work will deliver a particular value back to the customer/PO. Outlines desired outcomes. Has estimate time Is time boxed A good User Story has Title and proper IDs DOD (Definition of Done) Description Time duration and Time stamps Review method Review and Rework time estimation Task description Ordered steps

32. Criteria for User story: INVEST 1/18/2023 I ndependent: User story should be independent of other stories. They can relate to same feature. N egotiable: User stories are not a contract. They are negotiable. But it’s advised to not change a user story once the sprint has started. V aluable: User story should provide clear business value to customer/features in the immediate milestone delivery. E stimable: Stories need to be clear enough to estimate (for the appropriate timeframe), without being too detailed. Task construction must be easily possible. S mall: User story duration should be same as sprint duration. T estable: Stories need to be worded clearly and specifically enough to be testable.

33. User Story Format 1/18/2023

34. User story Checks 1/18/2023 It does not combine with, overlap nor conflict with other User Stories. It is independent of other user stories. It is traceable back to the business needs expressed in the business case and project objectives for immediate/current milestone. Duration should be 1 sprint (exceptions for smaller user story are possible but they should be justified in description). Task creation must be easy. Hence, create the possible task in sprint planning itself while creating the user story. Review and rework task are to be included. The created user-story must be workable in current sprint. It should not be having dependencies. If still a user story with dependency is considered, then the reason for taking it in current sprint must be justified in description. User story inputs and deliverables must be clearly defined in description. It should be assigned to one team member. User story does not have a parent task. Start date for user story should be Sprint start date and Due date of user story should be sprint end date*. The watchers should be added to a user story if any stake holder wants to monitor the task regularly. This point should be captured in sprint review. User story has properly defined acceptance criteria.

35. T a s k s 1/18/2023 3 5 What is Task? Should be completed by 1 person in the team Should be created at the start of the sprint Should be outcome focused. Outlines desired outcomes. Has estimate time Is time boxed A good Task is 1-2 3-4 Should take a day to complete Closed with a proper comment Estimated for a day Time duration and Time stamps Precisely Scoped Defined Inputs Defined Exit Criteria

36. Definition of Done 1/18/2023 What is DoD? It is a comprehensive checklist of necessary activities that ensure that only truly done features are delivered, not only in terms of functionality but in terms of quality as well. DoD Levels DoD for a Product Backlog item (e.g. writing code, tests and all necessary documentation) DoD for a Sprint (e.g. install demo system for review) Q111Q1Q DoD for a Release (e.g. writing release notes) Characteristics of DOD Doesn’t remail same throughout the project Must get refined and enhanced with time. Checklist of DOD for user story : 10 Golden rules Assumptions of User Story/sprint/release met Project builds without errors Unit tests written and passing Project deployed on the test environment identical to production platform Tests on devices/browsers listed in the project assumptions passed In lined with Epic and hence with feature Tested against Acceptance criteria Refactoring completed Any configuration or build changes documented Peer Code Review performed

37. Acceptance Criteria 1/18/2023 What is Acceptance Criteria? It is a comprehensive checklist of necessary activities that ensure that only truly done features are delivered, not only in terms of functionality but in terms of quality as well. Process for user story: 3Cs The Card: A written description of the User Story. It is instead a reminder for subsequent communication that must take place. The Conversation: Its used to discuss details of the User Story. It may be supplemented by some documentation. The Confirmation: Its represented by user acceptance tests, which ensure that the User Story satisfies acceptance criteria of the user/customer. Properties of acceptance criteria Testable Clear and concise Everyone must understand Provides user perspective Always aligned with Sprint goal Criteria/Checklist of acceptance criteria : SMART S: Specific M: Measurable A: Acceptable R: Realistic T: Testable