Agile Development – Why requirements matter
1 like•616 views
The document discusses the critical role of requirements management in agile development, emphasizing that requirements can and should change throughout the development process. It highlights that poor requirements management can lead to project failures and significant cost overruns, and stresses the need for structure, communication, and documentation at the right times. The document also outlines how effective requirements management is integral to successfully delivering software that meets user needs and expectations.
Agile Development – Why requirements matter
- 1. Agile Development Why Requirements Matter Fariz Saracevic ([email protected]) Senior Offering Manager IBM @FarizSaracevic
- 2. 2 AGENDA Why are requirements needed? Right-Sized Agile Requirements Management • Understanding your requirements management needs • Choices, choices… What’s Next?
- 3. 3 What Agile Development is NOT? Agile is NOT • prescribed software development process (like RUP) • strict set of rules you must exactly follow • excuse to avoid design, documentation or difficult tasks you can benefit from • guidance against requirements management, documentation, and doing what is right for you It is OK to incorporate traditional Requirements Definition and Management (RDM) practices into agile development • Requirements can (and will) change • Change can come from any source: retrospectives, customers or architectural re-iterations • Change can come any time: before, during and after you elaborated/implemented your story Requirements Definition and Management (RDM)
- 4. 4 You know that: • Requirements can (and will) change • Change can come from any source: retrospectives, customers or architectural re-iterations • Change can come any time: before, during and after you elaborated/implemented your story To embrace to change you need structure and organization Stating the facts…
- 5. 5 Agile manifesto requires structure and organization * Individuals and interactions over process and tools * Work product over comprehensive documentation * Customer collaborating over contract negotiation * Responding to change over following a plan Communicate but use tools to support you Document as needed and at the right time But don’t forget about all your stakeholders and complex relationships Still plan, but focus on getting started vs. long-term plan
- 6. 6 No perceived value • Requirements should not be just a checkbox in a checklist No real use for the requirements • Requirements used to take a lot of time to develop • After development, they sat on the shelf for too long • Design, tests and code should follow requirements. If not, they are useless. They change • All the time, any time • Unmanaged change is very frustrating Why are requirements a burden?
- 7. 7 Why are requirements needed? Increased Compliance and Regulatory Requirements 10 million lines of code in GM Volt Mars Rover Curiosity had 16000+ requirements Multiple vendors and supply chain contractors Smarter Products & Systems Complex Requirements Increased number of stakeholders Collaboration Across the Value Chain Effective Requirements Management
- 8. 8 Why are requirements needed? Marine One Helicopters Fiasco Costs mushroomed to $11.2B from $6.1B Gaudi’s Unfinished Cathedral 100+ year old project still not complete The Defense Science Board issued a new study blaming “poor communication” about aircraft requirements between the government and contractors. The only existing copy of Gaudí’s last recorded blue prints were destroyed by the anarchists in 1938 during the Spanish Civil War. La Sagrada Família is now being completed, but differences between his work and the new additions can be seen.
- 9. 9 Where human safety is a factor, even simple devices and systems require careful engineering to reduce risk
- 10. 10 Why requirements matter? If you ask for the wrong thing, you’ll get it… If you don’t know what was asked for, you’ll deliver the wrong thing… You need to understand what problem you’re trying to solve, get feedback early and often and then adjust… This is all about Agile way of working…
- 11. 11 Poor Requirements Management has a Significant Impact on your Business Requirements Rework Errors, late detected in the Maintenance phase can cost up to 200 times more than detected early in Requirement Analysis phase More than 40% of development budget can be consumed by poor requirements Project Impacts 41% of projects fail to deliver the expected business value and ROI 49% of projects overrun original estimates 28% of projects on time and on budget Project Delays Being late to market by 6 months or more will cost organizations 33% of the 5-year ROI “Our research indicates 80-plus percent of development failures result directly from poor requirements gathering, management, and analysis.” IDC, November 2007
- 12. 12 How do we know what we have built? The development team won’t be there for ever. Someone has to maintain and extend the system. A list of user stories does not give a sufficient picture. Team’s memory Team members can find information about work done in previous Sprints without having to dig through stacks of “done” user stories Product owner/business analysts memory To inform the creation of new user stories User documentation and training material development Why Requirements Management is (still) important in an agile way of working? Requirements can be viewed as:
- 13. 13 Requirements are only written when needed and detailed enough to know how to implement the system Requirements are written just in time, to help understand and decompose items on the backlog Capture decisions as they are made Do as much as you need, but not more! Documenting your system as it is being built enables you to better reuse work when developing the next feature/component/system, saving both time and money If you are fundamentally opposed to calling such decisions “requirements” then don’t. But still capture them!
- 14. 14 Product Owner • Product Vision • Product backlog prioritization • Represents the client often high level Architect • Technical consistency and quality • Often interfaces with Product Owner Development Team • Get further information on what to implement • Recall details of how finished parts of the system work Make requirements elaboration a core feature team activity Feature Team 1 Architect Dev Team Scrum Master Product Owner Feature Team 2 Architect Dev Team Scrum Master Product Owner
- 15. 15 Defect Story Task Project Collection Module Backlog Ranked Backlog Release Plan Project Plan Item Affects Implements Friend CCM RM Artifact UX Design Requirement Diagram Implements Use and link traditional requirements and agile artifacts
- 16. 16 Documentation over memorization 16 Complexity Sprint 1 Sprint 2 Sprint 3 Next Sprint
- 17. 17 The term “Requirement” is loosely used to including all requirements-related information • Textual requirement • Use Case • Usage Scenario • Feature Descriptions • Diagrams and Sketches • User Story • Story Elaborations • Etc These are not all strictly requirements, the same points apply to all Many of these are not found on the backlog Informal terminology notes
- 18. 18 Capture the work you are doing Document your decisions Connect the related information All these things count as requirements • Diagrams and Sketches • User Story • Story Elaborations • Textual requirement • Use Case • Usage Scenario • Feature Descriptions • Retrospective Document relevant information
- 19. 19 Common perception when you create traceability separately • That is making life hard for yourself • When you enter information you have the source available • So create trace information at the same time Do the right thing at the right time is the essence of agile It is insane to do it any other time! But traceability is too much work
- 20. 20 Providing good examples (and counter examples) of requirements • enhance the quality, consistency and completeness of their requirements • teach through “culture and practices” instead of documentation Structure • Artifact data model (requirement types) • Link Types • Workflow Templates • Folder structure & tags • Pre-defined views • Document templates • Project templates Provide structure and examples
- 21. 21 Products are becoming much more complex Products are becoming part of larger solutions / ecosystems Disrupt or be disrupted: innovating faster than competitors Three Key Challenges More software Hardware – Electronics – Software More suppliers More teams More specialists More subsystems Learning fast Deciding fast Acting fast Delivering fast From “predictable world” to “unpredictable world” Safety and security … and new failure modes Teams on-prem and on cloud Teams on different cadences
- 22. 22 Requirements in IBM DevOps Customer / Stakeholder Product Manager / Product Owner Dev Lead Requirement Feature Dev Work Item Continuous Customer Feedback & Optimization Collaborative Development Continuous Release and Deployment Continuous Monitoring Continuous Business Planning Continuous Testing Operate Develop/ Test Deploy Steer DevOps Continuous Feedback Requirements are the key artifact representing feedback… Requirements drive articulation of application features… Development delivers function for features…
- 23. 23 Rational Team Concert (RTC) Development Change Control Board (CCB) Design and develop software (SCM) Triage Enhancements / defects Backlog (Work items) Customer / Stakeholder Product owner / manager Dev Lead Software Engineer Analyse Specific work items can be put into the product backlog and delivered against directly Requirements
- 24. 24 Rational DOORS Next Generation (RDNG) Change Control Board (CCB) Triage Enhancements / defects Backlog (Work items) Customer / Stakeholder Product owner / manager Dev Lead Analyse Requirements Requirements Analysis Requirements Analysis System Requirements User RequirementsSpecify Requirements Analysis transforms many disparate inputs from different stakeholders into specific Requirements for the development team to work against.
- 25. 25 Rational Team Concert (RTC) Rational DOORS Next Generation (RDNG) Change Control Board (CCB) Triage Enhancements / defects Backlog (Work items) Customer / Stakeholder Product owner / manager Dev Lead Analyse Requirements Requirements Analysis System Requirements User RequirementsSpecify Deployment Design and develop software (SCM) Software Engineer These two activities can be executed in the same organisation with Requirements elaborating what business need the development team is aiming to solve.
- 26. 26 Requirements in Scaled Agile Framework (SAFe) Scaled Agile Framework (SAFe) with the Power of DevOps Requirements articulated in Portfolio Planning and refined through analysis into Features and Stories…
- 27. 27 Rational DOORS Next Generation Choices, choices… Rational Team Concert How do you choose?
- 28. 28 Understanding your requirements management needs Regulated/System Enterprises Need for regulatory compliance and auditing Separation of roles (Business Analysts, Development) Requirement governance Robust requirements articulation needs Rational DOORS Next Generation Small Agile Teams Unregulated, little or no compliance or audit requirements Desire for single tool lightweight requirements and change management Simple requirements articulation needs Rational Team Concert
- 29. 29 IBM Rational Team Concert Requirements simplicity for Small Agile Teams RTC Quick Planner • Easy to learn • Fast work item creation • Manage a backlog and sprints in a single window using drag and drop • Manage Parent/Child tasks and their rank relationships • IBM Design driven task based UI Reporting • Jazz Reporting Service • Fast data collection • Query builder • Lean reports Collaboration • Activity streams to track events • Automated work item reply • Social flow for comments • Manage & preview attachments Kanban/Taskboard • States and State-groups • Customize card display • Customize display of states • Display small, medium, large cards Build & Deploy • Post Build Deploy using UC Deploy • Gated control of builds for deployment Compliance for SCM • Improved large team usage with pessimistic locking • Improved auditing for work item link changes • Ability to see who and when code changes were delivered Integration • Git • Jenkins
- 30. 30 Better requirements… Less rework… Better results! IBM Rational DOORS Next Generation Enhance your value and capability beyond RTC for requirements Search, filter on attributes Business Objectives Business Processes Use Cases Storyboards & Sketches Reporting Industry & Domain Models Impact & Coverage analysis Rich text Requirements Traceability between related artifacts Rational DOORS Next Generation Definition and Management Lifecycle Traceability Project Efficiency and Reuse Improves the developer’s ability to design UI and software flow in the initial design phase Better define and manage rich text use cases, visual diagrams or processes Strengthens stakeholder’s traceability across all lifecycle artifacts to find missing requirements or use cases Easily discover the impact from requirement or use case changes Reuse requirements for multiple projects to lower development costs and capitalize on best practice Enables the development experience through a specification structures
- 31. 31
- 32. 32 “Agile is quickly becoming the most popular way of developing software because it ... more quickly deliver value to the end users. That value will be driven to a large extent by the quality and clarity of requirements that feed the software development process. An agile, lean, and timely approach to requirements as the starting point will help to ensure that the process is optimized.” Scrum Alliance Agile Requirements Definition and Management Feb 2012
- 33. 33 • Yes, if done correctly, at the right time, and to the right level! • Yes, everything isn’t captured on the backlog! • Yes, we need to know what you have built! • Managing requirements does not need to be a burden • Requirements management is possible and quite necessary in agile development • You need to understand the relationships between sets of information and that is most of what RM is about We’re Agile now. Do we really need Requirements Management?