Requirements on the verge
of a nervous breakdown
Tom Grant
Senior Consultant
Agile 2014

© 2014 Tom Grant
Thank You!
Tom Grant
tgrant@cutter.com
@TomGrantPhD
© 2014 Tom Grant

2
© 2013 Forrester Research, Inc. Reproduction Prohibited

© 2011 Israel Gat

3
100% of ALM
assessments
uncover
serious
problems
that start in
requirements

© 2013 Forrester Research, Inc. Reproduction ...
Stakeholders want more from their

© 2011 Israel Gat

5
“Which of the following technology
inititiatives are you asking IT to prioritize over
the next 12 months?”
0%

10%

20%

3...
“For each pair of statements, which best describes your firm?”
Stable

Business processes are consistent
across groups / B...
“How would you rate the quality of your team’s working
relationship with other parts of your company?”
0.0%

20.0%

40.0%
...
Requirements need attention right now
Improving requirements cited
more frequently (66%) than
any other area needing
atten...
Agile has accelerated this crisis
Can requirements
keep pace with
Agile?

© 2013 Forrester Research, Inc. Reproduction Pro...
CONTINUOUS
DELIVERY

REQUIREMENTS
AGILE PRACTICES
IN THE DEV TEAM

© 2013 Forrester Research, Inc. Reproduction Prohibited...
Requirements often slow Agile teams

WATER

© 2011 Israel Gat

SCRUM

FALL
How do we avoid a breakdown?

© 2013 Forrester Research, Inc. Reproduction Prohibited

© 2011 Israel Gat

13
1. Requirements must define value

2. Build better requirements toolkits
3. Find the right cadence

4. Ask more of require...
REQUIREMENTS MUST DEFINE
VALUE
© 2011 Israel Gat
We build software for people unlike us

© 2011 Israel Gat
Requirements explain value
› How software helps business outcomes
› What elements make it less helpful
› Why users adopt
›...
We need more regular feedback

© 2011 Israel Gat
Design thinking and visualization accelerate
feedback

© 2011 Israel Gat
We need better insights

© 2013 Forrester Research, Inc. Reproduction Prohibited

© 2011 Israel Gat

20
© 2011 Israel Gat
Change the conversation

COST
FEATURE
Android app for activity management
$5,000
Custom pipeline stages
$2,000
More comple...
WE NEED BETTER
REQUIREMENTS TOOLKITS

© 2011 Israel Gat
Themes?
Epics?

Use
cases?
User
experience?
Visualization?
© 2013 Forrester Research, Inc. Reproduction Prohibited

© 2011...
Requirements aren’t simple
What is the
customer
Descriptive
asking for?

Actionable

Contextual

What is the customer real...
Translation is necessary

Descriptive

Actionable

Contextual

© 2011 Israel Gat
Requirements are a toolkit

Enhancem
ent
requests, c
hange
requests, i
deas

User
stories
Descriptive

Actionable

Context...
The toolkit must evolve
CHALLENGES

Faster
requirements
development
Faster feedback
More reliable
feedback
Faster translat...
The toolkit must evolve
Faster
requirements
development
Faster feedback
More reliable
feedback
Faster translation
Better
c...
Epics
Themes

Resourcing

Business value

Release
planning

© 2013 Forrester Research, Inc. Reproduction Prohibited

© 201...
Contextual information is crucial
DECISIONS

DESIGN

REST OF
THE VALUE
STREAM

CUSTOMER
CONVERSATIONS
© 2011 Israel Gat
FIND THE RIGHT CADENCE

© 2011 Israel Gat
LONG-TERM
Entire project/product timeline (years)
MEDIUM-TERM
Next user-relevant landmark (months)
SHORT-TERM
Next dev-rel...
When do we need the requirements? (examples)

Descriptive
Long

Actionable

Project/product
Initial backlog
plan

Contextu...
“Just in time” requirements take skill
 Cultivate the right sources
 Identify the right source to

answer the question
...
ASK MORE OF REQUIREMENTS
PROFESSIONALS

© 2011 Israel Gat
More skills and experiences needed
ECONOMICS
Descriptive

Actionable

Contextual

ANTHROPOLOGY
© 2011 Israel Gat

COMPUTER...
We need negotiators, not order takers

© 2011 Israel Gat
The BA job must change
Old BA World

New BA World

• Order takers

• Business partners

• Everything must be on the list

...
BAs need support and investment

Product managers
and business analysts
say that soft skills are
more important than
techn...
HOW DO YOU KNOW YOU’VE
IMPROVED?

© 2011 Israel Gat
How do you know you’re doing well?
If you treat
requirements
as a . . .

And you’ll share them
with . . .

Necessity

“Tha...
How do you know you’re doing well?
QUALITATIVE
Ask the community.

Call “go to” users or
stakeholders.
Review personas, us...
SLIDE ARCHIVE

© 2011 Tom Grant

44
Software professionals
are better inventors than
innovators

© 2011 Tom Grant
Many problems that start in requirements
 Many sources of problems
• Little or no business justification
• Wrong prioriti...
Business problems putting stress on requirements

Requirements tools are
one of the most rapidlyevolving parts of the ALM
...
But wait…Wasn’t Agile supposed to fix
everything?
Even though Agile is
certainly mainstream
(39%+ of teams), the
voice of ...
It’s easy to lose track of the customer

© 2011 Tom Grant
It’s easy to lose track of the customer

© 2011 Tom Grant
It’s easy to lose track of the customer

© 2011 Tom Grant
How do we fix this situation?
 Make the information more accurate
 Make the information more timely
 Make the insights ...
Accurate

© 2009 Forrester Research, Inc. Reproduction Prohibited
© 2011 Tom Grant
Feedback loops? Really?

© 2011 Tom Grant
Eating your own dog food is not enough

Because you’re
not a dog

© 2011 Tom Grant
Waterfall trained us to be fatalistic about
requirements

© 2011 Tom Grant
Design thinking and visualization accelerate
feedback

Push design earlier in
the process.
Push feedback earlier
in the pr...
Feedback is fine, but…
Do we know in
advance the right
questions to pose?

© 2011 Tom Grant
Requirements aren’t simple
What is the
customer
Descriptive
asking for?

Actionable

Contextual

What is the customer real...
Requirements are necessary
We get
through this
as quickly as
possible…

Descriptive

Actionable

Contextual

© 2011 Tom Gr...
Requirements are an exercise in translation

Descriptive

Actionable

Contextual

© 2011 Tom Grant
Requirements are a toolkit

Enhancem
ent
requests, c
hange
requests, i
deas

User
stories

Descriptive

Actionable

Contex...
Contextual information is crucial
 Contextual information improves
decision-making
– Reduces the number of options
under ...
Contextual information lost at every toss

TESTER

DEVELOPER
“What should the software do?
Within what parameters for
secu...
But accuracy isn’t everything

Accuracy is fine, but
we do need to get on
with the work.

© 2011 Tom Grant
Timely

© 2009 Forrester Research, Inc. Reproduction Prohibited
© 2011 Tom Grant
Requirements can slow Agile teams

WATER

© 2011 Tom Grant

SCRUM

FALL
When do we need the requirements, really?

LONG-TERM
Entire project/product timeline (years)
MEDIUM-TERM
Next user-relevan...
When do we need the requirements? (examples)

Descriptive
Long
Medium

Short

© 2011 Tom Grant

Actionable

Contextual

Pr...
Requirements structure and process needs
changing
 Requirements toolkit, not requirements template
 Requirements pipelin...
But timeliness is not enough

Velocity
is down
here

© 2011 Tom Grant
Profound

© 2009 Forrester Research, Inc. Reproduction Prohibited
© 2011 Tom Grant
Are we having the best possible conversations?

One-on-one negotiations
between the business
faction and the IT faction
ar...
© 2011 Tom Grant
INPUT: Change the rules with serious games
 Structured

• Rules, but often no winners
 Purposeful

• Definite outcome
 ...
What sort of serious games?
Structured, gamelike activities with
collective outcomes

© 2011 Tom Grant
EXAMPLE: Product box

© 2011 Tom Grant
EXAMPLE: Buy a feature

COST
FEATURE
Android app for activity management
$5,000
Custom pipeline stages
$2,000
More complex...
Serious games change the conversation

Let the users wrangle
with each other, instead
of with you

© 2011 Tom Grant
Insight isn’t enough

Remember Agile? Lean?

© 2011 Tom Grant
Light-weight

© 2009 Forrester Research, Inc. Reproduction Prohibited
© 2011 Tom Grant
We just made the job of requirements a lot harder

© 2011 Tom Grant
More skills and experiences needed
ECONOMICS
Descriptive

Actionable

Contextual

ANTHROPOLOGY
© 2011 Tom Grant

COMPUTER
...
BAs need support and mentorship
When polled,
product managers
and business
analysts say that
soft skills are more
importan...
The top priority for PMs: requirements, over time

Source: Pragmatic Marketing survey
of product managers, 2010-2011.

© 2...
Agile ratchets up the pressure on BAs

The business

Development team
Waste

Waste

Has a problem

Business analyst

Provi...
The BA job must change
Old BA World

New BA World

• Order takers

• Business partners

• Everything must be on the list

...
If you want real super-heroes…

Give the people who
do requirements
responsibility AND
authority

© 2011 Tom Grant
Authority means that you can say…

© 2011 Tom Grant
We need BAs to be business innovation aces
 Possesses good research skills

 Knows how to get reliable answers

quickly
...
“Just in time” requirements take skill, resources
 Cultivate the right sources

• EX: Business users, social
media, past ...
“With great power comes great responsibility”

Measure and reward
adoption, or some
other positive
outcome

© 2011 Tom Gra...
People downstream need better requirements, too

WATER

© 2011 Tom Grant

SCRUM

FALL
Next steps

© 2009 Forrester Research, Inc. Reproduction Prohibited
© 2011 Tom Grant
How do you know you’re doing well?
If you treat
requirements
as a . . .

And you’ll share them
with . . .

Necessity

“Tha...
How do you know you’re doing well?
“The dev team has
a question . . .”

QUALITATIVE
Ask the community.
Call “go to” users ...
Step 1: Rethink your assumptions
 Potential techniques
• The “first hour” test
• Participant-observer
• “Product box” ser...
Step 2: Engage your customer in new ways
 Potential techniques
• Transparent road map
• Required “voice of the customer”
...
Step 3: Measure the value of the results
 Accuracy
• EX: How much re-work?

 Timeliness
• EX: How much on time?

 Insig...
Upcoming SlideShare
Loading in …5
×

Agile requirements, slide archive

601 views

Published on

Slides that I may be using for my presentation at Agile 2014

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
601
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Source: http://www.gettyimages.com/detail/sb10069978y-001/Photodisc
  • Source: www.balsamiq.com (screenshot)
  • Source: Getty Images (http://www.gettyimages.com/detail/108198052/Vetta)
  • Source: www.balsamiq.com (screenshot)
  • Source: Getty Images (http://www.gettyimages.com/detail/108198052/Vetta)
  • Source: Getty Images (http://www.gettyimages.com/detail/109722670/the-Agency-Collection)
  • Agile requirements, slide archive

    1. 1. Requirements on the verge of a nervous breakdown Tom Grant Senior Consultant Agile 2014 © 2014 Tom Grant
    2. 2. Thank You! Tom Grant tgrant@cutter.com @TomGrantPhD © 2014 Tom Grant 2
    3. 3. © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 3
    4. 4. 100% of ALM assessments uncover serious problems that start in requirements © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 4
    5. 5. Stakeholders want more from their © 2011 Israel Gat 5
    6. 6. “Which of the following technology inititiatives are you asking IT to prioritize over the next 12 months?” 0% 10% 20% 30% 40% 50% 60% Improve the use of data and analytics to improve business decisions and outcomes Improve IT project delivery performance Develop new skills to better support emerging technologies and business innovation Help the organization better manage and integrate its partners and suppliers Improve IT budget performance Base: 3,616 business decision-makers world-wide. Source: Forrsights Business Decision-Makers Survey Q4 2012 © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat High priority Critical priority Business needs results from software investments. Right now. 6
    7. 7. “For each pair of statements, which best describes your firm?” Stable Business processes are consistent across groups / Business processes are diverse across groups Changing 19% 32% 49% Consistent Our business environment/industry is stable / Our business environment/industry is rapidly changing Industry Neutral Diverse 22% 35% 43% Not just any software will do. Base: 3,616 business decision-makers world-wide. Source: Forrsights Business Decision-Makers Survey Q4 2012 © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 7
    8. 8. “How would you rate the quality of your team’s working relationship with other parts of your company?” 0.0% 20.0% 40.0% 60.0% 80.0% Testing/QA Other development teams IT operations Product management Business users Support/help desk Executive management 4 5 (Very good) Business analysts Business unit managers Enterprise architecture Security/risk management Marketing Program/portfolio management… Base: 1,614 software development professionals. Source: Forrester Q4 2012 Developer Survey © 2014 Tom Grant Software professionals don’t have a great affinity with the business.
    9. 9. Requirements need attention right now Improving requirements cited more frequently (66%) than any other area needing attention © 2011 Israel Gat Source: Q1 2011 Global Application Development & Delivery Organization Structure Online Survey; Getty Images (http://www.gettyimages.com)
    10. 10. Agile has accelerated this crisis Can requirements keep pace with Agile? © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 10
    11. 11. CONTINUOUS DELIVERY REQUIREMENTS AGILE PRACTICES IN THE DEV TEAM © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat DEVOPS 11
    12. 12. Requirements often slow Agile teams WATER © 2011 Israel Gat SCRUM FALL
    13. 13. How do we avoid a breakdown? © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 13
    14. 14. 1. Requirements must define value 2. Build better requirements toolkits 3. Find the right cadence 4. Ask more of requirements professionals © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 14
    15. 15. REQUIREMENTS MUST DEFINE VALUE © 2011 Israel Gat
    16. 16. We build software for people unlike us © 2011 Israel Gat
    17. 17. Requirements explain value › How software helps business outcomes › What elements make it less helpful › Why users adopt › How users adopt © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 17
    18. 18. We need more regular feedback © 2011 Israel Gat
    19. 19. Design thinking and visualization accelerate feedback © 2011 Israel Gat
    20. 20. We need better insights © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 20
    21. 21. © 2011 Israel Gat
    22. 22. Change the conversation COST FEATURE Android app for activity management $5,000 Custom pipeline stages $2,000 More complex lead-scoring options $3,500 More canned reports $1,500 Define and manage teams $4,750 Easy clean-up of bad or duplicate data $2,500 Activity entry via email $3,250 Associate teams with prospects $1,250 © 2011 Israel Gat SPENT $500 $300 $2,000 $2,500 -
    23. 23. WE NEED BETTER REQUIREMENTS TOOLKITS © 2011 Israel Gat
    24. 24. Themes? Epics? Use cases? User experience? Visualization? © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 24
    25. 25. Requirements aren’t simple What is the customer Descriptive asking for? Actionable Contextual What is the customer really asking for? © 2011 Israel Gat How should we meet the customer’s request?
    26. 26. Translation is necessary Descriptive Actionable Contextual © 2011 Israel Gat
    27. 27. Requirements are a toolkit Enhancem ent requests, c hange requests, i deas User stories Descriptive Actionable Contextual Personas, use cases, busine © 2011 Israel Gat Traditional requiremen ts Themes, e pics
    28. 28. The toolkit must evolve CHALLENGES Faster requirements development Faster feedback More reliable feedback Faster translation Better communication Better planning Greater re-use © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat TECHNIQUES Visualizations, pr ototypes, storyb oards Requirements tools Epics, themes Serious games Video/audio interviews 28
    29. 29. The toolkit must evolve Faster requirements development Faster feedback More reliable feedback Faster translation Better communication Better planning Greater re-use © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat Visualizations, pr ototypes, storyb oards Requirements tools Epics, themes Serious games Video/audio interviews 29
    30. 30. Epics Themes Resourcing Business value Release planning © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 30
    31. 31. Contextual information is crucial DECISIONS DESIGN REST OF THE VALUE STREAM CUSTOMER CONVERSATIONS © 2011 Israel Gat
    32. 32. FIND THE RIGHT CADENCE © 2011 Israel Gat
    33. 33. LONG-TERM Entire project/product timeline (years) MEDIUM-TERM Next user-relevant landmark (months) SHORT-TERM Next dev-relevant landmark (weeks) © 2011 Israel Gat
    34. 34. When do we need the requirements? (examples) Descriptive Long Actionable Project/product Initial backlog plan Contextual Personas Medium Re-prioritized backlog Themes/epics Use cases Short User stories (prioritization) User stories (design) User feedback © 2011 Israel Gat
    35. 35. “Just in time” requirements take skill  Cultivate the right sources  Identify the right source to answer the question  Triangulate using multiple sources  Deliver the actionable and contextual content that people need © 2011 Israel Gat
    36. 36. ASK MORE OF REQUIREMENTS PROFESSIONALS © 2011 Israel Gat
    37. 37. More skills and experiences needed ECONOMICS Descriptive Actionable Contextual ANTHROPOLOGY © 2011 Israel Gat COMPUTER SCIENCE
    38. 38. We need negotiators, not order takers © 2011 Israel Gat
    39. 39. The BA job must change Old BA World New BA World • Order takers • Business partners • Everything must be on the list • It’s on the list if it provides mutual value • Projects • Products • Focus on documentation • Focus on information • Requirements as a weapon • Requirements as a resource © 2011 Israel Gat
    40. 40. BAs need support and investment Product managers and business analysts say that soft skills are more important than technical domain knowledge. © 2011 Israel Gat The top 5 challenges for both product managers and business analysts are soft skills.
    41. 41. HOW DO YOU KNOW YOU’VE IMPROVED? © 2011 Israel Gat
    42. 42. How do you know you’re doing well? If you treat requirements as a . . . And you’ll share them with . . . Necessity “Thank God that’s done. Now, on to coding!” Just the development team. Catalyst “Wow, that new persona made me rethink our app.” The next person you’re trying to convince. Asset © 2011 Israel Gat You might find yourself saying . . . “When was the last time we looked at those user stories?” Everyone, in a format that makes sense to them.
    43. 43. How do you know you’re doing well? QUALITATIVE Ask the community. Call “go to” users or stakeholders. Review personas, use cases, other existing content. Answer a question in less than a day. QUANTITATIVE Collect usage stats. Do a quick poll. Analyze data from public sources (blogs, communities, etc.). © 2011 Israel Gat
    44. 44. SLIDE ARCHIVE © 2011 Tom Grant 44
    45. 45. Software professionals are better inventors than innovators © 2011 Tom Grant
    46. 46. Many problems that start in requirements  Many sources of problems • Little or no business justification • Wrong prioritization • Mistaken design choices • Insufficient functionality delivered • Too much functionality delivered  All boil down to some familiar measures of failure • Re-engineering, business/IT misalignment, etc. © 2011 Tom Grant
    47. 47. Business problems putting stress on requirements Requirements tools are one of the most rapidlyevolving parts of the ALM market © 2011 Tom Grant
    48. 48. But wait…Wasn’t Agile supposed to fix everything? Even though Agile is certainly mainstream (39%+ of teams), the voice of the customer is frequently not heard or understood Agile is a set of powerful, effective team-level practices for software development. It is not a silver bullet for every problem. © 2011 Tom Grant
    49. 49. It’s easy to lose track of the customer © 2011 Tom Grant
    50. 50. It’s easy to lose track of the customer © 2011 Tom Grant
    51. 51. It’s easy to lose track of the customer © 2011 Tom Grant
    52. 52. How do we fix this situation?  Make the information more accurate  Make the information more timely  Make the insights more profound  Make the information load lighter © 2011 Tom Grant
    53. 53. Accurate © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
    54. 54. Feedback loops? Really? © 2011 Tom Grant
    55. 55. Eating your own dog food is not enough Because you’re not a dog © 2011 Tom Grant
    56. 56. Waterfall trained us to be fatalistic about requirements © 2011 Tom Grant
    57. 57. Design thinking and visualization accelerate feedback Push design earlier in the process. Push feedback earlier in the process. © 2011 Tom Grant
    58. 58. Feedback is fine, but… Do we know in advance the right questions to pose? © 2011 Tom Grant
    59. 59. Requirements aren’t simple What is the customer Descriptive asking for? Actionable Contextual What is the customer really asking for? © 2011 Tom Grant How should we meet the customer’s request?
    60. 60. Requirements are necessary We get through this as quickly as possible… Descriptive Actionable Contextual © 2011 Tom Grant …So that we can get on with this
    61. 61. Requirements are an exercise in translation Descriptive Actionable Contextual © 2011 Tom Grant
    62. 62. Requirements are a toolkit Enhancem ent requests, c hange requests, i deas User stories Descriptive Actionable Contextual Personas, use cases, busine © 2011 Tom Grant Traditional requiremen ts Themes, e pics
    63. 63. Contextual information is crucial  Contextual information improves decision-making – Reduces the number of options under consideration – Leads to better design decisions – Improves communication with customers © 2011 Tom Grant
    64. 64. Contextual information lost at every toss TESTER DEVELOPER “What should the software do? Within what parameters for security, performance, etc.?” “Out of all the tests I might do, which represent the software as someone will actually use it?” UX DESIGNER BUSINESS ANALYST “Here’s the actionable © 2011 Tom Grant requirement” “What sort of user experience does the user expect? What would really win them over?”
    65. 65. But accuracy isn’t everything Accuracy is fine, but we do need to get on with the work. © 2011 Tom Grant
    66. 66. Timely © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
    67. 67. Requirements can slow Agile teams WATER © 2011 Tom Grant SCRUM FALL
    68. 68. When do we need the requirements, really? LONG-TERM Entire project/product timeline (years) MEDIUM-TERM Next user-relevant landmark (months) SHORT-TERM Next dev-relevant landmark (weeks) © 2011 Tom Grant
    69. 69. When do we need the requirements? (examples) Descriptive Long Medium Short © 2011 Tom Grant Actionable Contextual Project/product Initial backlog Personas plan Re-prioritized Themes/epics Use cases backlog User stories User stories User feedback (prioritization) (design)
    70. 70. Requirements structure and process needs changing  Requirements toolkit, not requirements template  Requirements pipeline, not a requirements bus  Requirements retrospection, not “fire and forget”  Business analysts and product owners who make decisions, not order-takers © 2011 Tom Grant
    71. 71. But timeliness is not enough Velocity is down here © 2011 Tom Grant
    72. 72. Profound © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
    73. 73. Are we having the best possible conversations? One-on-one negotiations between the business faction and the IT faction are hardly optimal © 2011 Tom Grant
    74. 74. © 2011 Tom Grant
    75. 75. INPUT: Change the rules with serious games  Structured • Rules, but often no winners  Purposeful • Definite outcome  Time-bound • By definition, a time-boxed exercise  Participatory • Success depends on everyone participating.  Egalitarian • Everyone has an equal opportunity to participate. © 2011 Tom Grant
    76. 76. What sort of serious games? Structured, gamelike activities with collective outcomes © 2011 Tom Grant
    77. 77. EXAMPLE: Product box © 2011 Tom Grant
    78. 78. EXAMPLE: Buy a feature COST FEATURE Android app for activity management $5,000 Custom pipeline stages $2,000 More complex lead-scoring options $3,500 More canned reports $1,500 Define and manage teams $4,750 Easy clean-up of bad or duplicate data $2,500 Activity entry via email $3,250 Associate teams with prospects $1,250 © 2011 Tom Grant SPENT $500 $300 $2,000 $2,500 -
    79. 79. Serious games change the conversation Let the users wrangle with each other, instead of with you © 2011 Tom Grant
    80. 80. Insight isn’t enough Remember Agile? Lean? © 2011 Tom Grant
    81. 81. Light-weight © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
    82. 82. We just made the job of requirements a lot harder © 2011 Tom Grant
    83. 83. More skills and experiences needed ECONOMICS Descriptive Actionable Contextual ANTHROPOLOGY © 2011 Tom Grant COMPUTER SCIENCE
    84. 84. BAs need support and mentorship When polled, product managers and business analysts say that soft skills are more important than technical domain knowledge. The top 5 challenges for both product managers and business analysts are soft skills. © 2011 Tom Grant
    85. 85. The top priority for PMs: requirements, over time Source: Pragmatic Marketing survey of product managers, 2010-2011. © 2011 Tom Grant
    86. 86. Agile ratchets up the pressure on BAs The business Development team Waste Waste Has a problem Business analyst Provides a solution Time Solution Documentation © 2011 Tom Grant
    87. 87. The BA job must change Old BA World New BA World • Order takers • Business partners • Everything must be on the list • It’s on the list if it provides mutual value • Projects • Products • Focus on documentation • Focus on information • Requirements as a weapon • Requirements as a resource We need someone to make smart decisions. And we need them now. © 2011 Tom Grant
    88. 88. If you want real super-heroes… Give the people who do requirements responsibility AND authority © 2011 Tom Grant
    89. 89. Authority means that you can say… © 2011 Tom Grant
    90. 90. We need BAs to be business innovation aces  Possesses good research skills  Knows how to get reliable answers quickly  Builds “just in time” requirements  Understands technical feasibility  Helps customers shape requirements  Has decision-making power  Turns requirements into an asset © 2011 Tom Grant
    91. 91. “Just in time” requirements take skill, resources  Cultivate the right sources • EX: Business users, social media, past requirements, etc. etc.  Identify the right source to answer the question • EX: Do we need insight or validation?  Triangulate using multiple sources • EX: One source provides depth, another ensures that the answer is representative  Deliver the actionable and © 2011 Tom Grant
    92. 92. “With great power comes great responsibility” Measure and reward adoption, or some other positive outcome © 2011 Tom Grant
    93. 93. People downstream need better requirements, too WATER © 2011 Tom Grant SCRUM FALL
    94. 94. Next steps © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
    95. 95. How do you know you’re doing well? If you treat requirements as a . . . And you’ll share them with . . . Necessity “Thank God that’s done. Now, on to coding!” Just the development team. Catalyst “Wow, that new persona made me rethink our app.” The next person you’re trying to convince. Commodity © 2011 Tom Grant You might find yourself saying . . . “When was the last time we looked at those user stories?” Everyone, in a format that makes sense to them.
    96. 96. How do you know you’re doing well? “The dev team has a question . . .” QUALITATIVE Ask the community. Call “go to” users or stakeholders. Review personas, use cases, other existing content. Someone can provide this information in less than a day. QUANTITATIVE Collect usage stats. Do a quick poll. Analyze data from public sources (blogs, communities, etc.). © 2011 Tom Grant
    97. 97. Step 1: Rethink your assumptions  Potential techniques • The “first hour” test • Participant-observer • “Product box” serious game © 2011 Tom Grant
    98. 98. Step 2: Engage your customer in new ways  Potential techniques • Transparent road map • Required “voice of the customer” at key intervals • Visualization • “Buy A Feature” serious game © 2011 Tom Grant
    99. 99. Step 3: Measure the value of the results  Accuracy • EX: How much re-work?  Timeliness • EX: How much on time?  Insight • EX: How much down-stream value?  Weight • EX: How much work to acquire? Source: Getty Images (http://www.gettyimages.com) © 2011 Tom Grant

    ×