Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fatma Urek Uludag - Discovery & Inception at Agile Practices

612 views

Published on

Discovery & Inception at Agile Practices

Published in: Engineering
  • Login to see the comments

Fatma Urek Uludag - Discovery & Inception at Agile Practices

  1. 1. DISCOVERY AND INCEPTION 
 AT AGILE PRACTICES
 FATMA ÜREK ULUDAĞ
  2. 2. © 2015 ThoughtWorks Yazılım Ltd. Şti. - Confidential - please do not distribute INNOVATION METHODS DISCOVER Research, explore and understand DEFINE Synthesise insights define the opportunity DESIGN Divergent ideation, prototype, validate ideas DELIVER Iteratively build, test with customers, refine Curiosity and empathy for your customers are often the inspiration for Innovation. The discovery phase does not have to be lengthy, just enough learning to define the problem you are trying to solve. The define stage is one of focus and convergence around the opportunity. Define your customer, your business model and your product hypothesis. This is where you set a vision and align your stakeholders. Guided by our vision, the design phase is divergent in nature, encouraging multiple ways of solving the problem. We rapidly prototype, test and refine the design and prepare for the delivery phase. In delivery, the focus shifts to robust execution as we plan the releases, build, iteratively test and refine the product. Through validation with customers we optimise the effectiveness of the product.
  3. 3. INNOVATION PIPELINE
 Enhance existing product offerings with customer research and idea generation, followed by rapid design and delivery. KINDS OF PROJECT PROJECT PLAN 1 PROJECT PLAN 2 PROJECT PLAN 3 NEW PRODUCT Get your idea to market fast, starting with light-weight customer research, followed by a 1 week inception, then build, measure and learn. 2 WEEK INCEPTION You have a mature product with well understood customers and a product vision – you are ready to deliver.
  4. 4. WHEN IS DISCOVERY NEEDED?
  5. 5. DISCOVERY ”The discovery stage should deliver just enough qualitative and quantitative data to have confidence that we understand the customer opportunity.”
 From Innovation Methods, ThoughtWorks
  6. 6. DISCOVERY OBJECTIVES CLARIFY THE BIG IDEAS THAT WE WILL BE DEVELOPING IN THE INCEPTION DEFINITION OF HIGH LEVEL SCOPE IDENTIFICATION OF COMPETITORS IDENTIFICATION OF PROJECT / PRODUCT SUCCESS CRITIERA
  7. 7. EXPERT REVIEW 7
  8. 8. COMPETITIVE REVIEW 8
  9. 9. FOCUS GROUP 9
  10. 10. OUTCOMES Clearly defined objectives for the product and supporting sites High level scope High level architectural and technical knowledge Agreed inception schedule
  11. 11. INCEPTION ”An inception is a collaboration of key stakeholders (including but not only most of the delivery team) to gain a shared understanding of vision, value and approach.”
 From Innovation Methods, ThoughtWorks
  12. 12. Highly collaborative and inclusive Time-boxed and rapid, focused on doing ‘just enough’ Feedback-driven and highly adaptive Is not upfront analysis Highly visual and workshop oriented to help evolve a vision for the project. HOW INCEPTIONS FEEL
  13. 13. INCEPTION OBJECTIVES BUILD A SHARED UNDERSTANDING OF PROJECT VISION AND GOALS EVALUATE HIGH-LEVEL SCOPE AND CORE PROCESSES EVALUATE KEY RISKS, ISSUES AND CONSTRAINTS IN DELIVERING TO THE END GOAL ESTABLISH TECHNICAL AND TESTING APPROACH
  14. 14. OUTCOMES All artifacts necessary to get started A prioritised list of features that deliver the most business value Consensus about the future state A shared vision of the solution Jointly produced system requirements A realistic, achievable plan for an early release of business value.
  15. 15. VISION
  16. 16. CREATE A SHARED VISION
  17. 17. UNDERSTAND BUSINESS VISION
  18. 18. FUTURESPECTIVE
  19. 19. TRADE-OFF SLIDERS
  20. 20. PERSONAS
  21. 21. PERSONAS Representations for your users/audience Further specification of roles - how people of the same role might use the system differently They represent the goals, motivations, characteristics and behaviour of a real group of users They are fictional, but based on fact
  22. 22. EXAMPLE PERSONA •• Hyper Harry The road warrior • About Harry: • Work is his life • Top salesman 4 years in a row • On the road 90% of the year • Mobile device junkie • Severely impatient “Stillness is death” Key Goals & Needs: • Anywhere, anytime access to data • Process my sale quickly
  23. 23. USER JOURNEYS
  24. 24. USER JOURNEY End-to-end journey Formula: user journey = persona + task + environment Looking to cover all the goals of the roles/personas Use user journeys to drive out requirements and to validate that solutions can solve the tasks identified in all possible environments.
  25. 25. USER JOURNEY
  26. 26. UNDERSTAND AND PROPOSE TECHNICAL SOLUTION
  27. 27. TECHNICAL APPROACH Technical visioning Architecture Proposed testing approach Addressing Non Functional Requirements (NFRs)
  28. 28. DESIGN: WIREFRAMES, PROTOTYPES, AND MOCK-UPS
  29. 29. WIREFRAMES, PROTOTYPES AND MOCK-UPS Models Represent screens and flow Lo-fi, Mid-fi Low cost, easy to change Helps test usability Components become stories
  30. 30. IDENTIFY & DISCUSS FEATURES AND STORIES
  31. 31. LEVELS OF REQUIREMENT Feature Epics Stories Tasks • Customer • Security • Letters • Customer Maintenance • Login • Deactivate Customer • Debtor • Debtor Maintenance • Forgot Password • Paid in full letters • Connect to LDAP • Collect all PIF letters • • Enter New • Missing Required • Find status of • Generate
  32. 32. STORY WRITING As a <type of user>, I want <some goal> so that <some reason>.
  33. 33. STORY WRITING I INDEPENDENT Self-contained, in a way that there is no inherent dependency on another user story. N NEGOTIABLE Can always be changed and rewritten, up until they are part of an iteration. V VALUABLE Must be able to deliver value to the end user or the business. E ESTIMABLE Be able estimate the size of a functionality, relative to the other stories. S SCALABLE
 (SMALL SIZED) Not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. T TESTABLE Provide the necessary information to make test development possible. How can you tell it is done?
  34. 34. Must Should Could Wouldn’t PRIORITISE
  35. 35. ESTIMATION
  36. 36. We should capture...
  37. 37. PREPARE RELEASE PLAN ITERATION N ITERATION N ITERATION N ITERATION NITERATION NITERATION 0 Inception START END Envolve/Handover Analyse Design Build Test Deploy
  38. 38. INCEPTION DELIVERABLES Business Vision and Project Objectives Prioritised High Level Requirements (Stories & NFRs) Technical Approach Visual Design Mock-ups Release Plan RAIDs & Communication Plan Next Steps
  39. 39. Questions? THANK YOU

×