Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Requirements: Whose job are they anyway?

•
•
allan kelly
allan kelly

This document discusses who is responsible for requirements in an agile development process. It notes that requirements engineering is often not well defined, leaving room for misunderstandings. Professionals like business analysts and product managers are best suited for requirements, but subject matter experts can also contribute specifications. Developers may assist but their primary skills are better applied elsewhere. The document emphasizes that requirements are essential and vacuums should be avoided, as others will fill the need even if not qualified. The product owner role from Scrum is described as an alias that may be held by various professionals.

1 of 29
DevConFu, Latvia November2013 Requirements: Who’s job are they anyway? allan kelly allan@allankelly.net Twitter: @allankellynet http://www.allankelly.net
Allan Kelly…  Consulting on software development & strategy  Training for Agile Author – Changing Software Development: Learning to be Agile (2008, Wiley) – Business Patterns for Software Developers (2012, Wiley - ISBN: 978-1119999249) – Xanpan: Reflections on agile (work in progress) https://leanpub.com/xanpan Chapters in… • Business Analysis and Leadership, Pullan & Archer 2013 • 97 Things Every Programmer Should Know, Henney, 2010 • Context Encapsulation in Pattern Languages of Program Design, vol#5, 2006
3 Styles of Agile Evolutionary • • • • Incremental • • • • Iterative • • • • Development team work in short iterations Regular releases Requirements emerge as team incorporates feedback and discovers new opportunities Cumulative flow diagrams Development team work in short iterations Minor releases frequent Formal requirements document start development with change request incorporated Burn-up more than burn-down Development team work in short iterations Major releases infrequent Formal requirements document (Salami Sliced) Formal change request process in place Burn-down to completion 4
Who does Requirements where you work?
Hang on! What is a Requirement anyway? And what’s the difference between a Requirement and a Specification?
Requirement or Specification? “A requirement is a stakeholderdesired, or needed, target or constraint” Tom Gilb “A ‘specification’ communicated one or more system ideas and/or descriptions to an intended audience. A specification is usually a formal, written means for communicating information” Competitive Engineering, 2005, p.400 & p. 418
A requirement is a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment. A specification describes machine behaviour sufficient to achieve the requirement. A specification is a restricted kind of requirement … Specifications are derived from requirements by reasoning about the environment, … These ideas, and some associated techniques of description, are illustrated by a simple example. Michael Jackson & Pamela Zave Deriving Specifications from Requirements: An Example, ACM Press 1995
Requirements & Specification • Specifications derive from Requirements – Requirements come first • A requirement – Is the desired outcome • A specification – Context specific – Contains details
Requirements go In Dev Team – Coders, Testers, etc. … Blue Cards Documents, Stories, User Stories, Cukes, Product Backlog Item, Quantum of Value (QoV) Business Value Increment (BVI) Working Software comes out
Requirements go In Dev Team – Coders, Tester s, etc. … Team need to know what is needed Working Software comes out Specifications be worked out inside if necessary
Requirements go In Working Software comes out Stakeholders don’t always agree Things change
An aside: Evaluation • Who does your evaluation? • What criteria do they use? Please please please! Close the loop!
Keep work flowing! Every 2 weeks…. Development Team Working software Teams will be more effective if arteries are clear
Requirements Engineering The Need Side Requirements go In Stakeholders don’t always agree Things change!
Nature Abhors: A Vacuum! • If you are lucky… – Someone will quietly come forward – They will be competent & passionate – They will double up their existing role • If you are unlucky… – Several people will assume the role – They be be incompetent & passionate – They will stop doing their existing role Grass Creative Commons license from WikiCommons by MarcusObal
Whose job a Requirements? It depends…
Business Analysts Business Partners Product Managers Product Analysts Architects, Developers, Dev Managers, Project Managers, Testers, SMEs, …. Well intentioned amateurs The Professionals Requirements Engineering
Requirements? Professionals Product Managers & Business Analysts Amateurs Subject Matter Experts Domain Experts Developers, Dev Managers, Project Managers, Testers, Architects….
Should developers do Reqs? • Possibly… – small work effort, small team • • • • Are they presentable to customers? Is it best use of their skills? Do they have time? Do they have empathy? – with users/stakeholders?
Architects? • Again: Is it the best use of skills? – Do they have the skills? – Do they have the time? • Generally: No – Architects have empathy with tech not people – Architects represent tech & code – Architects should be foil to Requirements people • Only for systems were technology dominates
And the SME/Domain Expert… • Sometimes • Subject Matter Experts are great for Specs – Know detail • But do they… – Have Big Picture? – Are they too close emotionally?
Rocket Scientists • Combine multiple skill sets – Domain knowledge, probably spent time in field – Technology, probably can code – Probably have a PhD • Probably have another title – BA, Product Manager, Architect, … – Chief Engineer – Just roll with it - Who cares about titles?
So who should? • Requirements Engineers – Business Analysts – Product Managers
Requirements Sub-Species Business Analyst “The answers are in this building” • Works: Corporate • Lives: Canary Wharf • Users • Wants: Happy Stakeholders • Measured by: Cost • Professional Proxy Product Manager “The answers are not in this building” • Works: Product Company • Lives: Silicon Valley • Customers • Wants: Happy Customers • Measure by: Revenue • Professional Customer Note: Plural of Customer is The Market
Product Owner huh? • Scrum Product Owner is the Bastard Child of Business Analyst and Product Managers – Neither one or other • Product Owner as defined by Scrum is a pale imitation of a Product Manager • Product Owner is the really important role – (but Scrum Master gets all the attention) • Product Owner is useful alias for a BA or PM – And others…
When worlds collide! “What’s the difference “A customer has a choice to use another product. A user doesn’t.” Allan Kelly between a user and a customer? The difference is a customer has given you their credit card data.” FT 28 Jan 2013 Worlds are increasingly overlapping • BAs need to pay more attention to out there • Prod Mgrs need to pay more attention to in here • Everyone needs to start with real customers
Feedback   
Take-away 1. Who’s job is it? – Horses for courses • • • • Business Analyst Product Manager Specialist SME Rocket Scientist SME 2. Do NOT tolerate vacuums 3. Product Owner is an alias http://blog.allankelly.net allan kelly Software Strategy Ltd. www.allankelly.net allan@allankelly.net Twitter: @allankellynet
Partners:

More Related Content

Requirements: Whose job are they anyway?

  • 1. DevConFu, Latvia November2013 Requirements: Who’s job are they anyway? allan kelly allan@allankelly.net Twitter: @allankellynet http://www.allankelly.net
  • 2. Allan Kelly…  Consulting on software development & strategy  Training for Agile Author – Changing Software Development: Learning to be Agile (2008, Wiley) – Business Patterns for Software Developers (2012, Wiley - ISBN: 978-1119999249) – Xanpan: Reflections on agile (work in progress) https://leanpub.com/xanpan Chapters in… • Business Analysis and Leadership, Pullan & Archer 2013 • 97 Things Every Programmer Should Know, Henney, 2010 • Context Encapsulation in Pattern Languages of Program Design, vol#5, 2006
  • 3. 3 Styles of Agile Evolutionary • • • • Incremental • • • • Iterative • • • • Development team work in short iterations Regular releases Requirements emerge as team incorporates feedback and discovers new opportunities Cumulative flow diagrams Development team work in short iterations Minor releases frequent Formal requirements document start development with change request incorporated Burn-up more than burn-down Development team work in short iterations Major releases infrequent Formal requirements document (Salami Sliced) Formal change request process in place Burn-down to completion 4
  • 5. Hang on! What is a Requirement anyway? And what’s the difference between a Requirement and a Specification?
  • 6. Requirement or Specification? “A requirement is a stakeholderdesired, or needed, target or constraint” Tom Gilb “A ‘specification’ communicated one or more system ideas and/or descriptions to an intended audience. A specification is usually a formal, written means for communicating information” Competitive Engineering, 2005, p.400 & p. 418
  • 7. A requirement is a desired relationship among phenomena of the environment of a system, to be brought about by the hardware/software machine that will be constructed and installed in the environment. A specification describes machine behaviour sufficient to achieve the requirement. A specification is a restricted kind of requirement … Specifications are derived from requirements by reasoning about the environment, … These ideas, and some associated techniques of description, are illustrated by a simple example. Michael Jackson & Pamela Zave Deriving Specifications from Requirements: An Example, ACM Press 1995
  • 8. Requirements & Specification • Specifications derive from Requirements – Requirements come first • A requirement – Is the desired outcome • A specification – Context specific – Contains details
  • 9. Requirements go In Dev Team – Coders, Testers, etc. … Blue Cards Documents, Stories, User Stories, Cukes, Product Backlog Item, Quantum of Value (QoV) Business Value Increment (BVI) Working Software comes out
  • 10. Requirements go In Dev Team – Coders, Tester s, etc. … Team need to know what is needed Working Software comes out Specifications be worked out inside if necessary
  • 11. Requirements go In Working Software comes out Stakeholders don’t always agree Things change
  • 12. An aside: Evaluation • Who does your evaluation? • What criteria do they use? Please please please! Close the loop!
  • 13. Keep work flowing! Every 2 weeks…. Development Team Working software Teams will be more effective if arteries are clear
  • 14. Requirements Engineering The Need Side Requirements go In Stakeholders don’t always agree Things change!
  • 15. Nature Abhors: A Vacuum! • If you are lucky… – Someone will quietly come forward – They will be competent & passionate – They will double up their existing role • If you are unlucky… – Several people will assume the role – They be be incompetent & passionate – They will stop doing their existing role Grass Creative Commons license from WikiCommons by MarcusObal
  • 17. Business Analysts Business Partners Product Managers Product Analysts Architects, Developers, Dev Managers, Project Managers, Testers, SMEs, …. Well intentioned amateurs The Professionals Requirements Engineering
  • 18. Requirements? Professionals Product Managers & Business Analysts Amateurs Subject Matter Experts Domain Experts Developers, Dev Managers, Project Managers, Testers, Architects….
  • 19. Should developers do Reqs? • Possibly… – small work effort, small team • • • • Are they presentable to customers? Is it best use of their skills? Do they have time? Do they have empathy? – with users/stakeholders?
  • 20. Architects? • Again: Is it the best use of skills? – Do they have the skills? – Do they have the time? • Generally: No – Architects have empathy with tech not people – Architects represent tech & code – Architects should be foil to Requirements people • Only for systems were technology dominates
  • 21. And the SME/Domain Expert… • Sometimes • Subject Matter Experts are great for Specs – Know detail • But do they… – Have Big Picture? – Are they too close emotionally?
  • 22. Rocket Scientists • Combine multiple skill sets – Domain knowledge, probably spent time in field – Technology, probably can code – Probably have a PhD • Probably have another title – BA, Product Manager, Architect, … – Chief Engineer – Just roll with it - Who cares about titles?
  • 23. So who should? • Requirements Engineers – Business Analysts – Product Managers
  • 24. Requirements Sub-Species Business Analyst “The answers are in this building” • Works: Corporate • Lives: Canary Wharf • Users • Wants: Happy Stakeholders • Measured by: Cost • Professional Proxy Product Manager “The answers are not in this building” • Works: Product Company • Lives: Silicon Valley • Customers • Wants: Happy Customers • Measure by: Revenue • Professional Customer Note: Plural of Customer is The Market
  • 25. Product Owner huh? • Scrum Product Owner is the Bastard Child of Business Analyst and Product Managers – Neither one or other • Product Owner as defined by Scrum is a pale imitation of a Product Manager • Product Owner is the really important role – (but Scrum Master gets all the attention) • Product Owner is useful alias for a BA or PM – And others…
  • 26. When worlds collide! “What’s the difference “A customer has a choice to use another product. A user doesn’t.” Allan Kelly between a user and a customer? The difference is a customer has given you their credit card data.” FT 28 Jan 2013 Worlds are increasingly overlapping • BAs need to pay more attention to out there • Prod Mgrs need to pay more attention to in here • Everyone needs to start with real customers
  • 28. Take-away 1. Who’s job is it? – Horses for courses • • • • Business Analyst Product Manager Specialist SME Rocket Scientist SME 2. Do NOT tolerate vacuums 3. Product Owner is an alias http://blog.allankelly.net allan kelly Software Strategy Ltd. www.allankelly.net allan@allankelly.net Twitter: @allankellynet