{"id":9004111223055942,"date":"2009-08-01T04:00:00","date_gmt":"2009-08-01T04:00:00","guid":{"rendered":"https:\/\/www.pragmaticinstitute.com\/uncategorized\/agile-market-requirements\/"},"modified":"2009-08-01T04:00:00","modified_gmt":"2009-08-01T04:00:00","slug":"agile-market-requirements","status":"publish","type":"resources","link":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/","title":{"rendered":"Agile Market Requirements"},"content":{"rendered":"<p>\u201cThe product shall.\u201d<\/p>\n<p>Market requirements typically define the problems your product will address using a formal, stilted language known to all technology people. For some reason, the verb shall be \u201cshall\u201d\u2014not \u201cshould\u201d or \u201cwill\u201d or \u201cmust\u201d or \u201cit\u2019d be neat if.\u201d Maybe it goes all the way back to the Ten Commandments: You Shall Honor Thy Father and Mother; You Shall Not Murder; You Shall Not Steal. You Shall Not Write Requirements Without the Verb Shall.<\/p>\n<p>I\u2019ve completely given up on formal requirements. We\u2019re just terrible at writing them; and, still, the development group wants more detail\u2014and more and more and more.<\/p>\n<h2>The requirement is the problem<\/h2>\n<p>Product managers write horrid requirements that are littered with buzzwords, ambivalent language, and non-specific performance parameters. They read like somewhat-technical marketing hype. And developers have to make sense of the requirements. They complain, \u201cI cannot program to these requirements.\u201d<\/p>\n<p>And they\u2019re right.<\/p>\n<p>So product managers try to become more specific by writing what I call ReqSpecs. Part problem, part implementation\u2014and impossible to use. Developers then complain, \u201cDon\u2019t tell me how to do my job,\u201d because the requirement now explains how the feature should be implemented.<\/p>\n<p>And they\u2019re right again.<\/p>\n<p>Developers say they cannot program to Product Management\u2019s requirements. And they\u2019re right. What they need is a functional specification. ReqSpecs don\u2019t solve the problem.<\/p>\n<p>Let\u2019s clarify some terms.<\/p>\n<p>A <em>requirement<\/em> is a short statement of the problem.<\/p>\n<p>A <em>specification<\/em> is a detailed description of how to solve the problem.<\/p>\n<p>Alan Cooper, often called \u201cthe father of Visual Basic\u201dand an expert in interaction design, argues that most projects fail because they do not have a spec at all. This is because most companies do not have product designers or architects. Product managers create desired feature lists; developers write code. But neither the product managers nor the developers are designing anything. Would you hire a carpenter to design a house? Of course not. You would hire an architect. Yet programmers often write complex software products without a design.<\/p>\n<p>Cooper suggests we add a role that is new to most Development organizations: the product designer. The designer analyzes the problems described in the requirements and then creates a specification, at a functional level, to describe how the problem can be solved with the product. The designer delivers a recommended approach to solving the problem, serving as the bridge between Product Management and Development.<\/p>\n<h2>What\u2019s a requirement?<\/h2>\n<p>In eXtreme Programming (XP), a requirement fits on an index card and is delivered in the form of a story. This requirement also comes with an implicit \u201cagreement to discuss,\u201d so that developers fully understand the problem.<\/p>\n<p>Rather than being in the requirement, implementation details must be in the specification. A specification is the designer\u2019s intended implementation to solve the problem.<\/p>\n<p>In his excellent series on \u201cPainless Functional Specifications\u201d (<a href=\"http:\/\/www.joelonsoftware.com\" target=\"_blank\" rel=\"noopener noreferrer\">www.joelonsoftware.com<\/a>), Joel Spolsky, CEO of Fog Creek Software, writes:<\/p>\n<blockquote><p><em>\u201c\u2026on any non-trivial project (more than about 1 week of coding or more than 1programmer), if you don\u2019t have a spec, you will always spend more time and create lower quality code.<\/em><\/p><\/blockquote>\n<blockquote><p><em>\u201cA functional specification describes how a product will work entirely from the user\u2019s perspective. It doesn\u2019t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on. A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.\u201d<\/em><\/p><\/blockquote>\n<p>So, a requirement states the problem; a specification states the solution. Spolsky defines two kinds of specification: functional, which is the intended approach to solving the problem; and technical, which is a detailed internal implementation.<\/p>\n<p>In the end, we all have a critical role to play:<\/p>\n<ul>\n<li>The product manager finds and quantifies market problems, articulating them in the form of requirements.<\/li>\n<li>The product designer writes a functional specification describing the approach to solving the problem.<\/li>\n<li>The product developer creates a technical specification that fully describes how the functional specification will be implemented.<\/li>\n<\/ul>\n<h2>Why the waterfall fails<\/h2>\n<p>Every company and every consultant has a laundry list of acronyms for the documents that must be produced: BRD, MRD, PRD, SRS. Enough already! There are only a few documents required: the problems (the basis of the market requirements document) and how we will solve them (a product specifications document).<\/p>\n<p>In the old days, tech companies followed the \u201cwaterfall\u201d model: Documents moved downstream one department at a time, from requirement to specification to build to test. But the final result\u2014the product\u2014looked nothing like the requirements. Product managers were always surprised in the end.<\/p>\n<p>The waterfall approach fails. What\u2019s missing from the waterfall is collaboration and iteration.<\/p>\n<p>Imagine going to a college seminar and not being able to ask the professor any questions! No matter whether or not you understand it, you\u2019re being tested on the lecture without being able to clarify any of the professor\u2019s points. How likely are you to do well in that course?<\/p>\n<p>And now imagine that college ends with a single exam\u2014without any tests along the way. In four or five years, you sit through 60 or more courses\u2013ranging from Western Civilization to a foreign language to biology to women\u2019s studies to macro economics to business law to volleyball. Now take a single exam to receive your diploma. No one could pass such an exam!<\/p>\n<p>Isn\u2019t it the same for products? Imagine a software development effort that takes multiple years to deliver\u2014without any opportunity to test your progress along the way.<\/p>\n<h2>Just say \u201cNo\u201d<\/h2>\n<p>Years ago, I joined a product team that was entering its third year of programming <em>without a product release<\/em>. Everyone on the team was despondent. Over the course of two or three years, every role had been filled more than once. Long ago, they had lost any hope of succeeding, and all of them were looking for jobs elsewhere.<\/p>\n<p>I took one look at the requirements and saw the problem: The executives were constantly adding new requirements. Every week brought new features to the list\u2014and features were being added to the list faster than they could be programmed into the product. The solution was simple: Someone\u2014and that someone was me\u2014had to stand up to the executives and tell them to stop! We were no longer accepting requirements for the next release. Here\u2019s how we did it.<\/p>\n<p>I worked with the development lead to make a comprehensive list of requests from our customers, executives, and salespeople. We estimated the effort for each request and put them all into a spreadsheet. It showed we had requests for more than 10 years worth of programming to do. I noted the contractual commitments that were pushing the strategic priorities to later in the roadmap. I showed the executive team the ramifications of their decisions.<\/p>\n<p>We needed someone to say \u201cNo\u201d to change. And I accepted the role.<\/p>\n<p>The Capability Maturity Model Integration (CMMI) defines the level of discipline in a company on a scale of 1-5\u2014from anarchy to nirvana. Wikipedia describes CMMI Level 1 this way:<\/p>\n<blockquote><p><em>At maturity level 1, processes are usually ad hoc and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.<\/em><\/p><\/blockquote>\n<p>Sound familiar? Does your company rely on the \u201cheroics of the people in the organization\u201d to deliver products? Most companies I encounter need a little more discipline. And they need it in the executive team\u2014not the rank and file. Someone needs to be there to reject all change requests.<\/p>\n<p>I frequently take the Acela train from Washington, DC to New York City. It leaves every hour, on the hour, and arrives in New York three hours later. Every time. Because once the train leaves the station, no one changes its destination. Like it or not, you\u2019re going to New York.<\/p>\n<p>Building products is like moving a train. It takes a longtime to get everyone organized; it takes a long time to get started; and, most of all, it is virtually impossible to change direction once the train has left the station. And the good news is that there\u2019s another train in an hour.<\/p>\n<h2>Agile is happening<\/h2>\n<p>The brilliance of agile development is that we break the job into small chunks, work for two weeks (or four), and deliver <em>something<\/em>. New requirements can always be added to the next chunk of work since we\u2019re starting a new iteration soon.<\/p>\n<p>Agile teams are designed to deliver small amounts of functionality with rapid iterations. Every two weeks, they deliver another product feature that could be released to the customers. Agile teams are designed to help companies be more responsive to market needs.<\/p>\n<p><em>Or are they?<\/em><\/p>\n<p>Agile is often an attempt to manage our executives rather than to be more responsive to the market. The executives keep changing their minds, adding new feature requests, flip-flopping on issues. The agile approach of development is a technique in forcing executives to choose.<\/p>\n<p>Agile development isn\u2019t so much a new approach to programming as it is a response to bad management. In the past, we spent too much effort documenting exactly what would be delivered before a line of code was actually written. We wasted too much energy getting precise estimates long before those estimates could be considered reliable.<\/p>\n<p>Everyone in Development knew these methods weren\u2019t working. But management didn\u2019t know. So developers became increasingly frustrated with the planning process. Management enforced dates that no one believed; management required detailed documentation and schedules long before the details were known. No wonder developers were frustrated.<\/p>\n<p>Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report. \u201cCompany name? Okay, 40 characters plus a space is 41. Invoice date? Six characters plus one space. What else?\u201d<\/p>\n<p>Then computing became a key part of every part of the business world. And the head of Development wanted to know how long you\u2019d be working in Accounting because the Manufacturing project needed your skills, too. And customers wanted to know how much the report would cost before they committed to the cross-department billing. And then HR wanted to know how many actual hours were spent in each area for internal billing of your time. These are all legitimate requests, aren\u2019t they?<\/p>\n<p>Working as a developer in a business involves working as a business\u2014which means sourcing and scheduling highly skilled workers.<\/p>\n<p>The big problem agile development is trying to address is not so much that management is bad; it\u2019s really that management is <em>early<\/em>. They want to know too much too soon\u2026long before the development team actually knows. They ask for estimates, get our guesses (and they are guesses), and then announce delivery dates for the project.<\/p>\n<p>Management mandates rigor and precision before the scope of the work is truly understood. \u201cHow long would it take you to build it?\u201d \u201cWell, that depends on what it is, doesn\u2019t it?\u201d \u201cYes, but give me a date anyway.\u201d Management over-commits Development all the time.<\/p>\n<p>Developers see the product managers as senior management\u2019s police force. And I have to admit that this is somewhat legitimate. Haven\u2019t many product managers imposed dates on projects they didn\u2019t truly understand? Haven\u2019t many product managers enforced process and documentation beyond what is necessary?<\/p>\n<p>So finance people and sales people and marketing people are making scheduling decisions for development projects they don\u2019t understand based on inadequate information. Sounds like a recipe for disaster. And it is. Thus, agile development was born!<\/p>\n<h2>Where does product management fit in agile?<\/h2>\n<p>One of the key aspects of agile programming is an onsite customer. While this makes sense in a custom programming environment where customer and developer are in the same building, it\u2019s unworkable for vendors.How do you have an onsite customer in a vendor model?<\/p>\n<p><strong>Answer:<\/strong> The product manager serves as the customer representative in planning and requirements definition.<\/p>\n<p>Building a repeatable product requires feedback from many customers, not just one. So someone needs to aggregate the requirements from many sources into a single coherent set of requirements. Answer: The product manager defines the requirements and the product roadmap for a market of customers.<\/p>\n<p>Delivering a product to a market of customers requires synchronizing the software, hardware, services, documentation, promotional programs, and sales tools to present a complete product to the marketplace. Answer: The product manager must integrate all schedules, so we can deliver and support the product in the market.<\/p>\n<p>As product managers, we should support the ideals of agile development. We want some process, but not too much process. Small iterations give us more flexibility to adapt to change. Team collaboration means less time is spent documenting, leaving more time for doing.<\/p>\n<p>We want to assist the team in delivering a complete product to a market and creating a product that people want to buy. Whether the product manager uses an Excel spreadsheet or a bunch of index cards wrapped in a rubber band, it\u2019s imperative to maintain a prioritized set of market problems to be solved in the next product iteration, as well as a vision for future product generations.<\/p>\n<p>Successful product teams are agile, combining collaboration with small iterations. The key to any agile team is building products that people want to buy. To do that, an agile team needs a messenger for the market, a product manager who thoroughly understands the problems facing today\u2019s customers. In agile programming\u2014and frankly in any programming model\u2014the effective product manager serves as representative of a market of customers.<\/p>\n<p><strong>Attend\u00a0<em><a href=\"\/course\/product\/build\/\"><em>Build<\/em><\/a> <\/em>to learn more about the role of product management in an agile development process<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Product managers write horrid requirements that are littered with buzzwords, ambivalent language, and non-specific performance parameters. They read like somewhat-technical marketing hype. And developers have to make sense of the requirements. <br \/> <em><\/em><\/p>\n","protected":false},"author":414,"featured_media":9004111222585616,"menu_order":0,"template":"","categories":[9004111222497210,9004111222509561],"tags":[],"content-series":[],"content-format":[9004111223037711],"framework-box":[177,174],"vertical":[131],"ppma_author":[1262],"class_list":["post-9004111223055942","resources","type-resources","status-publish","has-post-thumbnail","hentry","category-product-development","category-product-management","content-format-article","framework-box-fw-buyer-personas","framework-box-fw-planning","vertical-product","author-pragmatic-institute-expert-training-for-data-design-product"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Be Agile: Building a Successful Product Team | Pragmatic Institute - Resources<\/title>\n<meta name=\"description\" content=\"Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Be Agile: Building a Successful Product Team | Pragmatic Institute - Resources\" \/>\n<meta property=\"og:description\" content=\"Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/\" \/>\n<meta property=\"og:site_name\" content=\"Pragmatic Institute - Resources\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1280\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"12 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/\",\"name\":\"Be Agile: Building a Successful Product Team | Pragmatic Institute - Resources\",\"isPartOf\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg\",\"datePublished\":\"2009-08-01T04:00:00+00:00\",\"description\":\"Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#primaryimage\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg\",\"contentUrl\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg\",\"width\":1920,\"height\":1280,\"caption\":\"Photo By Brooke Cagle on Unsplash\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.pragmaticinstitute.com\/resources\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Resources\",\"item\":\"https:\/\/www.pragmaticinstitute.com\/resources\/resources\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Agile Market Requirements\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#website\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/\",\"name\":\"Pragmatic Institute\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#organization\"},\"alternateName\":\"Pragmatic\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.pragmaticinstitute.com\/resources\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#organization\",\"name\":\"Pragmatic Institute\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png\",\"contentUrl\":\"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png\",\"width\":216,\"height\":224,\"caption\":\"Pragmatic Institute\"},\"image\":{\"@id\":\"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Be Agile: Building a Successful Product Team | Pragmatic Institute - Resources","description":"Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/","og_locale":"en_US","og_type":"article","og_title":"Be Agile: Building a Successful Product Team | Pragmatic Institute - Resources","og_description":"Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report.","og_url":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/","og_site_name":"Pragmatic Institute - Resources","og_image":[{"width":1920,"height":1280,"url":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/","url":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/","name":"Be Agile: Building a Successful Product Team | Pragmatic Institute - Resources","isPartOf":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#primaryimage"},"image":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#primaryimage"},"thumbnailUrl":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg","datePublished":"2009-08-01T04:00:00+00:00","description":"Long ago, we used to be agile. A customer would ask for a report, and we\u2019d show up with 132-character wide grid paper to design the report.","breadcrumb":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#primaryimage","url":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg","contentUrl":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2009\/08\/Agile-Market-Requirements.jpg","width":1920,"height":1280,"caption":"Photo By Brooke Cagle on Unsplash"},{"@type":"BreadcrumbList","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/articles\/product\/agile-market-requirements\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.pragmaticinstitute.com\/resources\/"},{"@type":"ListItem","position":2,"name":"Resources","item":"https:\/\/www.pragmaticinstitute.com\/resources\/resources\/"},{"@type":"ListItem","position":3,"name":"Agile Market Requirements"}]},{"@type":"WebSite","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#website","url":"https:\/\/www.pragmaticinstitute.com\/resources\/","name":"Pragmatic Institute","description":"","publisher":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#organization"},"alternateName":"Pragmatic","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.pragmaticinstitute.com\/resources\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#organization","name":"Pragmatic Institute","url":"https:\/\/www.pragmaticinstitute.com\/resources\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/","url":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png","contentUrl":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-content\/uploads\/sites\/6\/2021\/09\/The_Pragmatic_Institute_Stacked_Logo.png","width":216,"height":224,"caption":"Pragmatic Institute"},"image":{"@id":"https:\/\/www.pragmaticinstitute.com\/resources\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/resources\/9004111223055942","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/resources"}],"about":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/types\/resources"}],"author":[{"embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/users\/414"}],"version-history":[{"count":0,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/resources\/9004111223055942\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/media\/9004111222585616"}],"wp:attachment":[{"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/media?parent=9004111223055942"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/categories?post=9004111223055942"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/tags?post=9004111223055942"},{"taxonomy":"content-series","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/content-series?post=9004111223055942"},{"taxonomy":"content-format","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/content-format?post=9004111223055942"},{"taxonomy":"framework-box","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/framework-box?post=9004111223055942"},{"taxonomy":"vertical","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/vertical?post=9004111223055942"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.pragmaticinstitute.com\/resources\/wp-json\/wp\/v2\/ppma_author?post=9004111223055942"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}