Enterprise Agile IT
Requirements Management
IEEE Software Technology Conference
04/02/2014
Learn. Perform. Succeed.
Matthew R. Kennedy, PhD, CSP
[email protected]
What is Agility?
• “The speed of operations within an organization
and speed in responding to customers (reduced
cycle times)” (Mass. Inst. Tech.)
Three+ Requirement Truths
1. You can’t gather all the requirements up front
2. The requirements you do gather will change
3. There is always more to do than time and money
will allow
4. Your estimates will be off*
* Added to the Agile Samurai Truths
Your Estimates Will Be Off
Knowledge Work
TECHNOLOGY
SPEED LIMIT
Example Operational Requirement
Create an exact hand written copy of 300 pages from a
T
historical book!
How much will this cost?
• Assumptions
– Section text is double-spaced, left-aligned, and set
in a 12-point Courier font.
– The first line of a paragraph is indented one half
inch, or 5 characters, from the margin.
– The margins are set so that there are 25 lines per
page, with each line having a maximum of 60
characters.
– Sixty characters per line at an average of six
characters per word works out to an average of ten
words per line.
It’s Math – It has to be Accurate,
Right?
• FORMULA: # lines/page x (char/line x 6 char
per/word) = words per page
• 25 x (60 / 6) = 250 words per page!
• 300 (Pages) x 250 (Words) = 75,000 words to
copy!
“Parametric” Words Per Minute
Estimate
• The average human being hand-writes 22 words
per minute while copying.*
– 75,000 (total words) / 22 (words per minute) = 3,409
minutes to copy 300 pages
• 3,409 (total minutes) / 480 (minutes in an 8-hour
day) = 7.1 Days (assuming 1 person)
*Brown, C. M. (1988). Human-computer interface design guidelines.
Norwood, NJ: Ablex Publishing.
Experiment
– Given a typed paragraph I asked 28 IT Professionals
to estimate how many words per minute they could
copy
The Numbers
• N=28
– Total 1,127 Years of Experience (in hand writing)
– Average 40.25 years of Experience (in hand writing)
Results
80
High 70
70
Words per Minute
60
50
40
36
30
20
Low 15
10
0
Average
Paragraph 1
Estimate
Actual
Results
80
High 70
70
Words per Minute
60
50
High 47
40
36
27
30
20
Low 15
Low 13
10
0
Average
Average
Paragraph 1
Estimate
Actual
Results
80
High 70
70
Words per Minute
60
50
40
High 47
High 45
36
27
27
30
Low 15
Low 15
Low 13
20
10
0
Average
Average
Paragraph 2
Paragraph 1
Estimate
Average
Actual
Estimate
Actual
Results
80
High 70
70
Words per Minute
60
50
40
High 47
High 45
36
30
27
27
26
20
Low 15
Low 15
10
Low 13
0
Average
Average
Average
Paragraph 2
Paragraph 1
Estimate
Average
Actual
Estimate
Actual
What If…
• You estimate using the high (70) estimate but
the team performs at the average (36) rate
– High: 75,000 Words / 70 WPM = 1,071 Minutes Hours
– Average: 75,000 Words / 36 WPM = 2,083 Minutes Hours
Jan
Feb
March April
May
June
July
Aug
Sep
Oct
Nov
Dec
High Estimate (1,071 hours)
~ 6 Months estimated delivery
Average (2,083 hours)
~ 1 Year to actually deliver
WPM = Words-per-minute
Or What If…
• You estimate using the Low (15) estimate but
the team performs at the average (36) rate
– Low: 75,000 Words / 15 WPM = 5,000 Minutes Hours
– Average: 75,000 Words / 36 WPM = 2,083 Minutes Hours
Jan
Feb
March April
May
June
July
Aug
Sep
Oct
Nov
Dec
High Estimate (5,000 hours)
2+ Years estimated delivery
High Estimate Cont…
Average (2,083 hours)
~ 1 Year to actually deliver
WPM = Words-per-minute
Project Variables
•
•
•
•
Cost
Schedule (Time)
Quality
Capability
Cost
• Typically tied to schedule (see Schedule) but
not always:
– Material cost (I.e., Titanium vs stainless steel)
– Increased / decreased performance (hardware)
– Etc…
Schedule (Time)
• Long project schedules or schedule delays may
cause additional schedule delays or an obsolete
product since:
– User needs change
• Causing additional requirements late in the process to
address these changes -> adding to the schedule
– Technology changes
• May require hardware changes -> adding to the schedule
Quality
• Pay me now… Or pay me later…
– Increased cost to repair later in development
– Increase in support costs (Help Desk)
– Decrease user trust
Capability
• Decreased user trust
Project Variables
•
•
•
•
Cost
Schedule (Time)
Quality
Capability
Project Variables
Capability
Capability
Quality
Quality
Cost
= Fixed
Schedule
Cost
Schedule
Aspects of Product Development
• Business Aspect
– Responsible for the overall acquisition:
contracting, funding, operational requirements, and
system delivery structure
• Project / System Aspect
– Overall technical management. Further decompose
the requirements and allocate them to software or
hardware
• Development Aspect
– Developmental items
Project / System
Aspect
Locked Requirements
Business Aspect
Traditional Requirements
Management
How long (time) will it take to complete these requirements?
How much will it cost to complete these requirements?
Locked Requirements
Traditional Delivery
At what point can we ACCURATELY readjust our cost estimate?
When can we adapt to changing requirements?
Requirement 1
Design
Requirement 1
Build
Requirement 1
Test
Requirement 2
Design
Requirement 2
Build
Requirement 2
Test
Requirement 3
Design
Requirement 3
Build
Requirement 3
Test
Requirement 4
Design
Requirement 4
Build
Requirement 4
Test
Requirement n
Design
Requirement n
Build
Requirement n
Test
Integration
Acceptance Testing
Estimated Time – Likely to be extended
First time capability is achieved
Project / System
Aspect
Business Aspect
Traditional Requirements
Management
Using What We Know
• We can’t get everything done [Prioritization]
• Time is a critical factor [Time Boxing / Short Time-lines]
Agile Practices
Incremental Development
Small Teams
Iterative Development
Time Boxing
Short Time-lines
Lean Initiatives
Retrospectives (Lessons learned)
Prototyping
Empowered / Self-organizing / Managing
teams
Prioritized Product Backlog
(Requirements)
Continuous User
Involvement
Co-located Teams
Kennedy / Ward
How do we Prioritize Enterprise
Requirements?
• Numerically?
• Relative to each other?
• Groups?
MoSCoW* (Groups)
Must Have (or Minimum Usable Subset)
Should Have
Could Have
Won’t Have (but Would Like in Future)
Increased Priority
•
•
•
•
* Used in Dynamic Systems Development Method
Must
Should
Could
Won’t
Agile Requirements Management
Project / System
Aspect
Increased Priority
Business
Aspect
Increment 1
Must
Should
Could
Won’t
Given this priority, budget and time what capability can be completed?
Agile Requirements Management
Project / System
Aspect
“Must”
Requirement 1
“Must”
Requirement 2
Reprioritize / Add /
Remove
Requirements
“Must”
Requirement n
“Should”
Requirement 1
Must
Increased Priority
Won’t
Increased Priority
Could
Agile Delivery Must
Should
Shouldcan we ACCURATELY readjust
At what point
our cost
Could
Could
estimate?
Won’t
Won’tcan we adapt to changing
At what point
requirements?
Minimum Capability Achieved –Other
Requirements may be pushed
to a future increment
Should
Reprioritize / Add /
Remove
Requirements
Increased Priority
Business Aspect
Must
Increment n
Increment 2
Increment 1
“Should”
Requirement 2
“Should”
Requirement 4
“Should”
Requirement 6
“Could”
Requirement 1
“Should”
Requirement 3
“Should”
Requirement 5
“Should”
Requirement 7
“Could”
Requirement n
Time-Box
= Time-Boxed Sub-capability
More Tools to Manage Risk
• Specify SHORT delivery times
– Generally, the longer the deliver time the greater the
risk
• Prioritize the requirements
– Ensure high priority requirements get completed
first
• Working capabilities are the only measure of
success
Final Thought
• There are NO extra-ordinary programs…. Just
programs that do ORDINARY things better!
[email protected]
Requirements Must Have A…
• Specified level of Testable Quality (Acceptance
criteria)
• Priority (Must, Should, Could, Won’t)
– Everything CAN’T be a MUST!
• Estimated Level of Effort (time-boxed period to
complete each requirement)
To the Maximum Extent Possible
Requirements…
• Must be developed in priority order
• Must meet the minimum level of predefined
acceptable quality and no more
• Must be estimated by the developers performing
the work
Cultural Barriers
• Pushed capability vs. added time / $$
• Multidisciplinary teams vs. domain focused
teams
• Stove-piped / domain focused contracts
Agile Requirements Management
• Agile requirements management requires agile
project / systems engineering practices.
– This requires an organizational change
– Capability based development
Agile IT Encompasses All Forms of
IT Development
DRAFT DoD-Agile-IT Handbook