Problem solve Get help with specific problems with your technologies, process and projects.

Do business stakeholders lose requirements ownership in Agile?

The iterative nature of Agile means that requirements must be revisited frequently, which changes the dynamic amongst business stakeholders.

When an IT team uses Agile processes, does development take ownership of the requirements away from the business?

Good Agile teams make it clear that they do not support big up-front requirements (BUFR) when they are developing code. They incorporate the discovery of requirements as part of the cadence of developing the product. They do this through management ("grooming") of the product backlog throughout the product lifecycle. This does not mean, however, that the business stakeholders lose ownership of the requirements.  

The business is forced to exercise its ownership of the requirements process in a way that works with the cadence of incremental delivery. In exchange, the business is taught (or forced) to discover and document requirements in a better way.

While an Agile team eschews the BUFR notion and refuses to wait for someone to do exhaustive analysis and requirements documentation, the team does not abandon requirements gathering entirely. Before writing any code, a good team will require a T-shaped understanding of the requirements -- a broad but shallow understanding of the overall space, combined with a deep but narrow understanding of whatever is to be done first. You have to have breadth of understanding in order to choose what to do first -- or you risk building irrelevant things first, while critical expectations lie fallow and unmet. Your goal is to create a minimally market-viable product (MVP) as quickly as possible.

Good Agile teams are cross-functional, which often means cross-departmental from a reporting standpoint. The teams self-organize, and all the members have operational responsibilities to the other team members. They deliver working software together, even though they may have HR-reporting structures that are independent. A Scrum team, for example, could have members from development, QA, UX and the business. The product owner is the person responsible for articulating the details of the "deep" part of the T. That product owner can either be a stakeholder or the person responsible for gathering those requirements from and managing the expectations of the business.

Ideally, a product manager is also part of the team, responsible for developing and sharing the broad view, articulating the strategic initiatives and vision for the product, combined with articulating the tactics the business will take that are the root cause for determining which "spike" is the most important one. Most teams are understaffed, however, and place the responsibilities for both depth and breadth on one person's shoulders.

While there are nontrivial operational benefits to developing software with an iterative cadence, the real value comes from infusing your team with the opportunities to gain increased understanding of the market. That comes through iterative feedback cycles from actual customers, based on the incrementally evolving product.

A BUFR process starts with a lot of research that, because there is no product (yet) that allows you to gather feedback, is built upon a lot of assumptions. Those assumptions come mainly in the form of putting each "spike" of requirements areas in a relative priority order and in understanding the details of the requirements within each spike. A BUFR project usually waits until everything is done before validating the assumptions and confirming that what was built is what the market needs and wants.  

An incremental process starts with the same assumptions about relative priority and the same assumptions about the details of a single spike. When the results of creating a solution to the first spike's requirements are presented to customers, the team can get feedback immediately about the relative priority of "whatever should be next" -- and most teams that I've worked with will re-order the anticipated sequence of solving problems. The team also gets feedback about that initial spike, giving them an opportunity to fix mistakes (not just coding errors, but also design errors and requirements errors) before the end of the project.

Presenting something to customers will get you much better feedback than asking them to imagine a solution. Remember, even if you have a vision of the end result, your business stakeholders probably don't.

This feedback loop is not just going to the developers and designers; it is also going back to the business. The business is responsible for correcting its misunderstanding of the market and using this additional knowledge to "get smarter." Just because it happens within the cadence of product creation defined by the development team does not mean that the business has lost ownership of the requirements. It just means that the business is expected to do what they should have been doing anyway.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.