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

1. Agile Requirement Development
A Breathtakingly Quick Introduction
By Juhani Lind, Agile Trainer and Coach

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
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
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. 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
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
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. 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
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. 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. 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. 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. 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. 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
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
Getting Started with
Agile Requirement Development
v 1.0

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
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. 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
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