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.

Agile Requirement Development - A Breathtakingly Quick Introduction

847 views

Published on

Tieturin Senior Consultant Juhani Lindin tekemässä diasetissä kerrotaan, mitä on ketterä määrittely.

Published in: Technology
  • Be the first to comment

Agile Requirement Development - A Breathtakingly Quick Introduction

  1. 1. Agile Requirement Development A Breathtakingly Quick Introduction By Juhani Lind, Agile Trainer and Coach
  2. 2. 2 Positioning Requirements and Agility Start coding NOW. I check what the customer wants. Wait … WAIT. I need to first figure out ALL the requirements. • Neither of the extremity is great • Requirements seldom have absolute value in themselves! • The primary goal should always be to target the working solution • Requirements and specifications are an invaluable vehicle to achieve this since the WHAT question stills needs to be answered before HOW v 1.0 Agile Requirement Development
  3. 3. 3 Agile or Not – The System Context Matters! Processes. Business Rules. User Experience. User-Interface. Reports. Features. Functionality. Quality Requirements. Security. Data Requirements. External Interfaces. Services. v 1.0 Business Opportunities. Business Needs. Stakeholders. User Roles. Personas. External/Internal Events. State Transitions. System Under Development Constraints. Standards. Regulations. Legislation. Agile Requirement Development Traceability. System Life-Cycle. Maintenance. System Criticality. Development Risks. System Size.
  4. 4. 4 Examples Agile Practices On Different Levels Steering Development For example Scrum and Kanban: Definition of Done, Product Owner, Review Meeting, Retrospective, Vision … Requirement Development Architecting Design Implementation Acceptance Criteria/Tests Definition of Ready Illustrating with Examples Specifying Collaboratively Splitting Requirements Validating Frequently Coding Standards Continuous Integration Refactoring Test Driven Development … Testing Agile Test Strategy Exploratory Testing … Common Practices Agile Modeling, Daily Meeting, Effort Estimation, Pair Working, Prioritization, Provide Continuous Feedback, Test Automation, Test-First Strategy … v 1.0 Agile Requirement Development
  5. 5. The Good Old Requirement Development Activities Are Still Here! Requirement Analysis Requirement Elicitation (Discovery) Requirement Specification v 1.0 Agile Requirement Development 5
  6. 6. 6 Applying Agility To The Activities! Performing activities just-in-time. Eating the elephant one piece at a time. 1 2 3 4 v 1.0 Activities are a team effort involving all the roles. Writing requirements in a concise way favouring - pictures - charts, diagrams - lists - tables over long text. Ruthlessly prioritizing the requirements. Agile Requirement Development Clarifying and refining requirements by discussing with customer representatives.
  7. 7. 7 Enabling Smooth Development Look for opportunities to develop a single requirement in small pieces and to get feedback. Analyze. Specify. Test. Next Backlog Item v 1.0 Agile Requirement Development Analyze. Specify. Design. Build. Test. Design. Build.
  8. 8. Example: Scrum and Requirement Development 1.A… 8 8 2.B… 13 (Elicitation) Analysis Specification 1.A… 8 2.B… 13 3.C… 5 Elicitation 8 3.C… 5 Sprint planning 4.D… 20 Plan 5.E… 13 Sprint Backlog 6.F… 40 7.G… ? Product Backlog Retrospective (Elicitation) Analysis Specification Sprint review Elicitation, Validation v 1.0 Agile Requirement Development Daily Scrum Potentially shippable increment of functionality
  9. 9. 9 Classic Requirement Modeling Techniques • There are plenty of modeling techniques that help analyze and understand requirements • These are applicable also to Agile Requirement Development Context Diagram. Process Maps. Process Diagrams. Activity Diagrams. Prototypes. UI Wireframe. Feature Trees. Use Case Diagram. Story Map. Dialog Map. Examples. Scenarios. Entity/Relationship Diagrams. Class Models. Class-Responsibility-Collaboration (CRC) Cards. v 1.0 Agile Requirement Development Event-Response Tables. Decision Tables. Decision Trees. Sequence Diagrams. Collaboration Diagrams. State Diagrams. Timing Diagrams.
  10. 10. Agile Modeling Principles and Practices Supporting Requirement Analysis Principles Practices • Assume Simplicity • Embrace Change • Enabling the Next Effort is Your Secondary Goal • Incremental Change • Maximize Stakeholder ROI • Model With a Purpose • Multiple Models • Quality Work • Rapid Feedback • Working Software Is Your Primary Goal • Travel Light • • • • • • • • • • • • • 10 Active Stakeholder Participation Apply the Right Artifact(s) Collective Ownership Create Several Models in Parallel Create Simple Content Depict Models Simply Display Models Publicly Iterate to Another Artifact Model in Small Increments Model With Others Prove it With Code Single Source Information Use the Simplest Tools Source: Agile Modeling website http://www.agilemodeling.com/ v 1.0 Agile Requirement Development
  11. 11. Practice: Specifying Collaboratively • Requirements development is like any other development activity – a team effort 11 • Typical collaboration models: • All-Together Workshops • Small Workshops • Every team member can contribute! • One representative from every development discipline • A great way to build a shared understanding among all parties involved in the development • Pair Writing • Frequent, informal discussions with Customer Representatives • What needs to be accomplished • Covering all the different aspects of a system • Choosing an appropriate model • Collaboration leads to requirements that are easy to understand v 1.0 • The maturity of the product • The level of domain knowledge in the team(s) • Estimated analysis effort • How readily Customer Representatives are available Agile Requirement Development
  12. 12. Practice: Splitting Requirements • Originally requirements may be large and vague (so-called epics) • But eventually requirements should be small and compact enough to enable estimation and development • Appropriately sized requirements improve transparency, manageability and steering • That is enhanced risk management! 12 • Different ways to split requirements are for example • By workflows • By usage scenariosn • By input, output and configuration types • By data presentation formats • By data classification • By creating, searching, updating and deleting data • By user roles • By system operations • Nevertheless each split requirement has to deliver valuable functionality for the customer v 1.0 Agile Requirement Development
  13. 13. Practice: Acceptance Criteria • A classic, but sadly forgotten, requirement for requirements and features is they can be verified and preferably validated as well • Building the right thing the right way –thinking • Acceptance criteria capture how the customer knows that a requirement or a feature works as intended • Conditions that software must satisfy to be accepted • Explicitly stated criteria are a quality tool for knowing what needs to be accomplished v 1.0 13 • Acceptance criteria assist in writing high-quality specifications because they force developers to think what is truly needed or required • Acceptance criteria can address both functional and nonfunctional (quality) aspects • The SMART acronym might be used as a guidance for writing great acceptance criteria • Specific – Measurable – Achievable – Relevant – Timebound • Acceptance criteria can be elaborated to automated acceptance tests Agile Requirement Development
  14. 14. Practice: Illustrating with Examples • Examples are actually used almost automatically when discussing requirements! • The power of the examples in Requirement Development is based on • • • • understandability ability to dispel ambiguities possibility to enhance communication and collaboration ability to make requirements concrete and inspire discussion • A good example to illustrate and clarify a requirement should be • accurate and precise • complete and comprehensive • as concrete as possible v 1.0 • realistic • and understandable to different stakeholders Agile Requirement Development 14
  15. 15. 15 Journey To Done via Definition of Ready Definition of Ready targets to ensure that the specification for a Product Backlog Item is good enough in terms of further development • Understood well enough • Granular enough for planning and design v 1.0 Agile Requirement Development
  16. 16. 16 Getting Started with Agile Requirement Development v 1.0
  17. 17. 17 Apply the Agile Principle #12! • Regular retrospective meetings are great places to discuss and analyze 12. Team reflects regularly where and how to improve • • • • • • What is working What is not working What could be improved What should we start doing What should we stop doing What have we learnt • W Edward Deming’s PDCA Cycle is a useful tool for continuous improvement • • • • v 1.0 P = Plan D = Do C = Check A = Act Agile Requirement Development
  18. 18. 18 Few Suggestions How to Proceed Keep the Improvement Backlog public Tackle only few improvements at a time Have courage to experiment Proceed with small steps to get feedback and to learn Remember to celebrate successes! v 1.0 Agile Requirement Development
  19. 19. Involve All Stakeholders to Get Feedback and Comments 19 Architecting Design Implementation Customer Representatives Requirement Engineering Testing Maintenance Application Management v 1.0 Agile Requirement Development
  20. 20. 20 Thank You! For further information please visit us at www.tieturi.fi and Agile Requirement Development Course (in Finnish) Helsinki, Tampere, Tukholma, Göteborg v 1.0 Agile Requirement Development

×