RULES OF REQUIREMENTS WITH SCOTT SEHLHORST
Moderated by Cindy F. Solomon
Founder, Global Product Management Talk
http://www.blogtalkradio.com/prodmgmttalk
cindy@prodmgmttalk.com
The most important thing a product manager will do is develop an understanding of their market. The second most important thing they will do is form a strategy for their product, given that understanding. The third most important thing is to communicate to the rest of the team what needs to be done, to implement that strategy, to win in that market.
That's why we write requirements - to communicate what needs to be built, as part of an approach to meeting the needs of a market. The rules of writing requirements help us communicate more effectively when writing requirements. Pretty narrow scope, pretty powerful impact.
About The Speaker, Scott Sehlhorst
Scott has been helping companies achieve Software Product Success since 1997, and started Tyner Blain in 2005. Scott is a strategy and product management consultant. He has also worked as a business analyst, technical consultant, software developer, project manager, program manager, and electro-mechanical design engineer. Scott has managed teams from 5 to 50, and delivered millions of dollars in value to his customers. http://tynerblain.com
Startup Product Summit
Discover how to work together to develop amazing products.
February 7, 2013, San Francisco
startupproduct.com
Registration is now open!
startupproduct.ticketbud.com/summit
Become a Product Leader!
2 Day Intensive: Product Innovation Leadership
February 5 & 6, San Francisco
http://www.aipmm.com/html/certification/strategic-innovation.php
Subscribe AIPMM Product Management News and Views:
http://www.aipmm.com/subscribe
LinkedIn: http://www.linkedin.com/company/aipmm
6. Scott Sehlhorst
Product management & strategy consultant
8 Years electromechanical design engineering (1990-1997)
IBM, Texas Instruments, Eaton
8 Years software development & requirements (1997-2005)
> 20 clients in Telecom, Computer HW, Heavy Eq., Consumer Durables
7+ Years product management consulting (2005-????)
>20 clients in B2B, B2C, B2B2C, ecommerce, global, mobile
Agile since 2001
Started Tyner Blain in 2005
Helping companies
Build the right products, right
6
7. Why Do We Care…
…About Writing Good Requirements?
9. Root Cause Analysis
Failure reasons Success factors
Lack of user input User involvement
Incomplete requirements Exec support
Changing requirements Clear requirements
Lack of exec support Proper planning
Tech. incompetence Realistic expectations
9
13. 3. Design-Free Requirements
This is really about trust.
The “stack” of problem
decomposition alternates
between requirements and
design.
A business is designed to focus on
solving particular problems.
A user designs an approach to
solving problems.
A product manager designs a set
of target capabilities that (should)
help the user and business.
The engineering team designs
solutions that embody those
capabilities
14. 4. Attainable Requirements
Can You Build It?
Existing Team
Available Technology
Internal Political Environment
Can You Launch It?
Organizational Dependencies
Legal Restrictions (National, Local, IP)
15. 5. Complete Requirements
You Cannot Absolutely
Determine Completeness
Objective Assessment
Have you identified all of
the problems to succeed in
the market?
Heuristic Assessment
Have you identified how to
completely solve the
problems?
16. 6. Consistent Requirements
Strategic Consistency
Does this requirement work in concert with others
to achieve our strategic goals?
Logical Consistency
A requires B
Must have A
Must not have B
Grammatical Consistency
Writing with the same tone, structure, phrasing…
17. 7. Unambiguous Requirements
Language Introduces Ambiguity
When Writing
Identify the user, the context, the goal
Be precise in language (avoid jargon, symbols)
When Reading
Shared language (e.g. “must” vs. “shall”)
Read The Ambiguity Handbook and you’ll be forever
paranoid about misinterpretation of everything you
ever write again. Ever.
18. 8. Verifiable Requirements
Does it Have a Measurable Aspect?
If not, how do you know if you delivered?
Do You Know the Measure of Success?
If not, how do you know what you need to deliver?
Do You Have the Ability to Measure It?
Aha! Time to write another requirement.
19. 9. Atomic Requirements
Every Requirement Stands on its Own
The Defining Characteristic:
A Requirement Cannot Be Half-Done. It is Either
Done, or Not Done.
20. 10. Passionate Requirements
Be Excited. Be Committed.
Care About
Your Customers & Their Problems
Your Company & Its Strategy
Your Team & Their Enrichment
Your Work & Its Quality
Have Passion
…It Will Show in Your Requirements
21. 11. Correct Requirements
Are You Focusing on the
Correct
Market Segments,
Customers, Problems?
Do You Know That These Are
the Right Requirements?
Can We Achieve Our Goals
Without These
Requirements?
22. 12. Stylish Requirements
Write Consistently Use Good Style
And With Good Style-> The System Must…
Prioritize Explicitly Intentional Perspective
Ordered Backlog, not Non-Negative
MoSCoW Reference, Don’t Repeat
Write for Your Audience Gender Indifference
Syntactic Parallelism
23.
24. Thank You!
Scott Sehlhorst
http://twitter.com/sehlhorst Twitter
http://tynerblain.com/blog Blog
http://go.tynerblain.com/sehlhorst About Me
http://www.slideshare.net/ssehlhorst SlideShare
https://plus.google.com/110352820346292209511 Google +
scott@tynerblain.com Email
scott.sehlhorst Skype
Agile since 2001
Started Tyner Blain in 2005
Helping Companies
Build The Right Thing, Right
24