Managing Requirements with Distributed Teams

1. Managing Requirements with Distributed Teams An Agile Practitioners’ Guide December 20, 2018

2. Challenge “Software requirements is a communication problem!” – Mike Cohn (Agile Coach, Mountain Goat Software) • Need a bridge between people who want things built and those actually building them • How do we do this effectively when a product owner and the development team have limited time to interact? • What level of detail does the remote development team need? Outcome: Shared understanding of what needs to be built. Clear expectations for both client and development team before kick-off.

3. Making of a pizza Size, Crust, Sauce, Toppings OR

4. Domain Familiarity of Dev Team vs. Available Requirements Granularity Low Domain Familiarity Medium High High Medium Low BDD / ATDD Vision only Available granularity of requirements

5. Domain Familiarity vs. Requirements Granularity - Example Low E.g. Pharmacy System Domain Familiarity E.g. Online Auction Platform E.g. Mobile Email Client High User Story w/ clear Acceptance Criteria User Story Epic Requirements Granularity High Low

6. Example – Mobile Email Client As a user, when I get an email notification on my device, I am able to access it immediately. Acceptance Criteria: • Swiping/tapping notification takes user to message directly • View shows conversation - if the new message was a reply, then it is displayed above the original • Message count is updated • Message is marked read after it is displayed

7. Example - Online Auction UI As a bidder, I want items from my search result to be organized by pages, so that I can navigate easily. Acceptance Criteria : • When search results are more than 20, a new page is displayed for the additional items. • Previous/Next buttons are shown. • Page count is displayed. • If page count is greater than 3, show links to pages 1, 2 and 3; then ellipses and the last page number. • Allow user to specify the number of results to be displayed per page, for example, 20, 50, 100.

8. Example – Pharmacy System As a pharmacy technician, I want the ability to update information for a given medication, so that it is specific to the patient.

9. Factors for Understanding Software Requirements Better • Domain / Industry familiarity • Available granularity of written requirements • Business requirement / Product vision • Transparency / collaboration • User perspective • Slicing of functionality - vertical or horizontal

10. Fundamentals of Good User Stories for Remote Teams • Context • Persona • Action • Expected outcome(s) • Drawing / Picture INVEST - Independent, Negotiable, Valuable, Estimable, Small, Testable User Stories by Mike Cohn https://www.youtube.com/watch?v=6q5-cVeNjCE

11. Big Picture / Story Map Time Product Epic Epic Epic Feature Feature Feature Feature Feature Feature Story Story Story Story Sprint N Story Story Story Story Story Story Story Story Sprint N+1 Story Story Story Story Story Story Story Story Story Story Backlog Story Story Story Story Story http://www.jpattonassociates.com/user-story-mapping/

12. Big picture / Story Map - Example Time Mobile email client Receive Messages Send Messages Multiple Mailboxes Notification View Format Spellcheck Gmail Yahoo! Story Story Story Story Sprint N Story Story Story Story Story Story Story Story Sprint N+1 Story Story Story Story Story Story Story Story Story Story Backlog Story Story Story Story Story http://www.jpattonassociates.com/user-story-mapping/

13. Product Manager, Product Owner Roles - Same or Different? Product owner (PO) works closely with development teams—elaborating users’ stories, managing sprint-level backlogs, expanding specifications, and interpreting product vision. (S)he address the agile development teams’ intense need for real-time input on user stories, user experience/user interface, and requirements. Product manager’s (PM) primary job is to meet existing customers and potential prospects and deeply understand what they want. A product manager, driven by the market, determines what goes into the final product, creating a 12-18 month roadmap. Product owners operating in close alignment with a product manager is a good approach to ensure product success. https://pragmaticmarketing.com/resources/articles/the-strategic-role-of-product-management-when-development-goes-agile

14. Typical Distributed Team • Product Manager, usually located closer to end customers’ geography • Product Owner, usually located closer to the dev team • Sometimes, Proxy Product Owner located close to the dev team • Local dev environment • Common source code control, issue tracking system, and all other infrastructure components on cloud • If needed, point-to-point VPN connection between remote sites

15. Process • Where is the client in the requirements process? • User Stories with acceptance criteria - does not mean every detail is covered but story contains basic acceptance criteria • User Stories – documents what needs to be built but missing acceptance criteria • Epic – High level description of features or activity • Determine level of product owner involvement - need for frequent feedback loop • Understand domain specific assumptions and constraints, for example, PHI data needs special handling • Set expectations about how the process is likely to unfold. Daily conversations between product owner and development team at the beginning of the project tapering down to 1-2 times/week

16. Product Manager (PM) / Product Owner (PO) Model Available Granularity Remote Team Role Client Role

17. What Synerzip Needs to Provide - to Complement/Support Client Low Dev + QA + PO + PM Domain Familiarity Dev + QA + PO Medium Dev + QA only High High Medium Low Available Granularity

18. Prescription for Synerzip Engagements Assess where the client team is on this map Based on that, what product management support Synerzip needs to provide Low Dev + QA + PO + PM Domain Familiarity Dev + QA + PO Medium Dev + QA only High High Medium Low Available Granularity

19. Examples

20. (LF) Example – Epic + Story • Epic description is available. Example: Edit patient-related information • Story description, if available, is at a high level • Developers/QA need a lot of time with PO to understand expectations • Assumption : Vision is to build the UI and backend for a retail pharmacy Story: As Phil, the pharmacy tech, I want the ability to customize prescription drug information for a patient, so that it is relevant to her/him. LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

21. (LF) Example – Epic + Story + Acceptance Criteria • Epic / Feature description is available. Example: Edit patient-related information • Story description is present but acceptance criteria is not fully fleshed • Developer/QA need details and clarifications from the PO • Basic UI design is available Story: As Phil, the pharmacy tech, I want the ability to customize prescription drug information for a patient, so that it is relevant to her/him. Acceptance Criteria: Detail 1: I am prompted to fill in mandatory information, such as dosage and timings Detail 2: I am prompted to fill in optional information LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

22. (LF) Example – Epic + Story + Acceptance Criteria + UI Design • Epic / Feature description is available. Example: Edit patient-related information • Story description and acceptance criteria has both necessary and sufficient details • Developer/QA needs little (if any) clarifications from the PO • Refined UI is available Story: As Phil, the pharmacy tech, I want the ability to customize prescription drug information for a patient, so that it is relevant to her/him. Acceptance Criteria: Detail 1: I am prompted to fill in mandatory information, such as dosage and timings Detail 2: Limit is 256 characters, all characters are allowed, including special ones Detail 3: All text is saved as it is being typed Note: Multiple stories like the above are needed to complete the epic LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

23. (MF) Example - Epic + Story • Epic description is available • Story description(s), if available, is at a high level • Developers/QA need a lot of time with PO to understand expectations • Assumption : Vision is to build a process automation tool UI Story : As Maggie, the mortgage loan manager, I want a reporting system, so that I can track data related to a mortgage application lifecycle. LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

24. (MF) Example - – Epic + Story + Acceptance Criteria • Epic / Feature description is available • Story description is present but acceptance criteria is not fully fleshed • Developer/QA need details and clarifications from the PO • Basic UI design is available Story example: As Maggie, the mortgage loan manager, I want to know the number of approved applications per month, so that I can determine if I need to increase/decrease staff. Acceptance Criteria: I can view the number of approved, rejected and total applications. LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

25. (MF) Example - Epic + Story + Acceptance Criteria + UI Design • Epic / Feature description is available • Story description and acceptance criteria has both necessary and sufficient details • Developer/QA needs little (if any) clarifications from the PO • Refined UI design is available Story: As Maggie, the mortgage loan manager, I want to know the number of approved applications per month, so that I can determine if I need to add more staff. Acceptance Criteria: I can view the number of approved, rejected and total applications in a given month. I can view the data as a pie chart or bar chart. I can change the period of reporting, example, pick last month instead of current month. Note: Multiple stories like the above are needed to complete the epic LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

26. (HF) Example - Epic + Story • Epic description is available • Story description(s), if available, is at a high level • Developers/QA need time with PO to understand expectations • Assumption : Vision is to manage multiple calendars via one application, which is accessed via web and mobile clients Story : As Olivia, the office manager, I want to view/edit multiple calendars in one application, so that I can efficiently manage team members’ schedules. LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

27. (HF) Example - Epic + Story + Acceptance Criteria • Epic / Feature description is available • Story description is present but acceptance criteria is not fully fleshed out • Developer/QA minor clarifications from the PO • Basic UX design is available Story: As Olivia, the office manager, I want to view my team members’ calendars in one application, so that I can manage the team’s schedule. Acceptance Criteria: I can view 5 members’ calendars. I can view the calendar in day, week or month format. LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

28. (HF) Example - Epic + Story + Acceptance Criteria • Epic / Feature description is available • Story description is present but acceptance criteria is not fully fleshed out • Developer/QA minor clarifications from the PO • Basic UX design is available Story: As Olivia, the office manager, I want to view my team members’ calendars in one application, so that I can manage the team’s schedule. Acceptance Criteria: I can view 5 members’ calendars. I can view the calendar in day, week or month format. LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

29. (HF) Example - Epic + Story + Detailed Acceptance Criteria • Epic / Feature description is available • Story description and acceptance criteria has both necessary and sufficient details • Developer/QA needs little (if any) clarifications from the PO Story: As Olivia, the office manager, I want to manage multiple calendars on one screen, so that I can keep the team calendar up to date. Acceptance Criteria: I can add up to 5 people’s calendars by adding their names. I can edit only 1 member’s calendar at any given time. Time slots are in increments of 30 minutes. Team member’s calendar is updated within 10 seconds of my adding an entry to their calendar. Note: Multiple stories like the above are needed to complete the epic LF – Low Familiarity, MF – Medium Familiarity, HF – High Familiarity

30. ‹#›

31. Your Trusted Agile Software Co-development Partner Accelerate delivery of your product/technology roadmap Address technology skills gap in your inhouse team Save >50% with Indiabased software development talent Leverage US based professionals to make it easy for your inhouse team to collaborate

32. Representative Clients - 14+ Years …100+ more

33. Upcoming Webinar Organizing & Scaling Agile Teams Wednesday, January 16, 2019 @ 1pm ET | Noon CT | 10am PT Presentor: Ron Lichty Agile Consultant & Author: Managing the Unmanageable