Agile requirements, slide archive
•Als POTX, PDF herunterladen•
2 gefällt mir•827 views
The document discusses challenges with requirements in agile software development projects. It suggests that requirements often slow down agile teams and fail to keep pace with faster development cycles. To address this, the document proposes that requirements need to: 1) Define business value more clearly; 2) Involve better requirements toolkits that evolve with new techniques; and 3) Find the right cadence of requirements at different stages of development. It also suggests asking more of requirements professionals by developing their skills in areas like design thinking.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Agile requirements, slide archive
Ähnlich wie Agile requirements, slide archive (20)
Mehr von Tom Grant
Mehr von Tom Grant (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Agile requirements, slide archive
- 1. Requirements on the verge of a nervous breakdown Tom Grant Senior Consultant Agile 2014 © 2014 Tom Grant
- 2. Thank You! Tom Grant tgrant@cutter.com @TomGrantPhD © 2014 Tom Grant 2
- 3. © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 3
- 4. 100% of ALM assessments uncover serious problems that start in requirements © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 4
- 5. Stakeholders want more from their © 2011 Israel Gat 5
- 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. “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. “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. 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. Agile has accelerated this crisis Can requirements keep pace with Agile? © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 10
- 11. CONTINUOUS DELIVERY REQUIREMENTS AGILE PRACTICES IN THE DEV TEAM © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat DEVOPS 11
- 12. Requirements often slow Agile teams WATER © 2011 Israel Gat SCRUM FALL
- 13. How do we avoid a breakdown? © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 13
- 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. REQUIREMENTS MUST DEFINE VALUE © 2011 Israel Gat
- 16. We build software for people unlike us © 2011 Israel Gat
- 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. We need more regular feedback © 2011 Israel Gat
- 19. Design thinking and visualization accelerate feedback © 2011 Israel Gat
- 20. We need better insights © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 20
- 21. © 2011 Israel Gat
- 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. WE NEED BETTER REQUIREMENTS TOOLKITS © 2011 Israel Gat
- 24. Themes? Epics? Use cases? User experience? Visualization? © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 24
- 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. Translation is necessary Descriptive Actionable Contextual © 2011 Israel Gat
- 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. 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. 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. Epics Themes Resourcing Business value Release planning © 2013 Forrester Research, Inc. Reproduction Prohibited © 2011 Israel Gat 30
- 31. Contextual information is crucial DECISIONS DESIGN REST OF THE VALUE STREAM CUSTOMER CONVERSATIONS © 2011 Israel Gat
- 32. FIND THE RIGHT CADENCE © 2011 Israel Gat
- 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. 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. “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. ASK MORE OF REQUIREMENTS PROFESSIONALS © 2011 Israel Gat
- 37. More skills and experiences needed ECONOMICS Descriptive Actionable Contextual ANTHROPOLOGY © 2011 Israel Gat COMPUTER SCIENCE
- 38. We need negotiators, not order takers © 2011 Israel Gat
- 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. 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. HOW DO YOU KNOW YOU’VE IMPROVED? © 2011 Israel Gat
- 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. 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. SLIDE ARCHIVE © 2011 Tom Grant 44
- 45. Software professionals are better inventors than innovators © 2011 Tom Grant
- 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. Business problems putting stress on requirements Requirements tools are one of the most rapidlyevolving parts of the ALM market © 2011 Tom Grant
- 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. It’s easy to lose track of the customer © 2011 Tom Grant
- 50. It’s easy to lose track of the customer © 2011 Tom Grant
- 51. It’s easy to lose track of the customer © 2011 Tom Grant
- 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. Accurate © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
- 54. Feedback loops? Really? © 2011 Tom Grant
- 55. Eating your own dog food is not enough Because you’re not a dog © 2011 Tom Grant
- 56. Waterfall trained us to be fatalistic about requirements © 2011 Tom Grant
- 57. Design thinking and visualization accelerate feedback Push design earlier in the process. Push feedback earlier in the process. © 2011 Tom Grant
- 58. Feedback is fine, but… Do we know in advance the right questions to pose? © 2011 Tom Grant
- 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. 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. Requirements are an exercise in translation Descriptive Actionable Contextual © 2011 Tom Grant
- 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. 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. 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. But accuracy isn’t everything Accuracy is fine, but we do need to get on with the work. © 2011 Tom Grant
- 66. Timely © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
- 67. Requirements can slow Agile teams WATER © 2011 Tom Grant SCRUM FALL
- 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. 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. 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. But timeliness is not enough Velocity is down here © 2011 Tom Grant
- 72. Profound © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
- 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. © 2011 Tom Grant
- 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. What sort of serious games? Structured, gamelike activities with collective outcomes © 2011 Tom Grant
- 77. EXAMPLE: Product box © 2011 Tom Grant
- 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. Serious games change the conversation Let the users wrangle with each other, instead of with you © 2011 Tom Grant
- 80. Insight isn’t enough Remember Agile? Lean? © 2011 Tom Grant
- 81. Light-weight © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
- 82. We just made the job of requirements a lot harder © 2011 Tom Grant
- 83. More skills and experiences needed ECONOMICS Descriptive Actionable Contextual ANTHROPOLOGY © 2011 Tom Grant COMPUTER SCIENCE
- 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. The top priority for PMs: requirements, over time Source: Pragmatic Marketing survey of product managers, 2010-2011. © 2011 Tom Grant
- 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. 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. If you want real super-heroes… Give the people who do requirements responsibility AND authority © 2011 Tom Grant
- 89. Authority means that you can say… © 2011 Tom Grant
- 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. “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. “With great power comes great responsibility” Measure and reward adoption, or some other positive outcome © 2011 Tom Grant
- 93. People downstream need better requirements, too WATER © 2011 Tom Grant SCRUM FALL
- 94. Next steps © 2009 Forrester Research, Inc. Reproduction Prohibited © 2011 Tom Grant
- 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. 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. Step 1: Rethink your assumptions Potential techniques • The “first hour” test • Participant-observer • “Product box” serious game © 2011 Tom Grant
- 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. 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
Hinweis der Redaktion
- 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)