The Product Backlog is the heart of defining any Agile solution. The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment. The challenge is that most Product Backlogs are based on input from selected stakeholders, rarely representing the full scope of requirements – and constraints – that need to be considered before priorities and business value can be accurately identified.
This is the first of two articles that provide you with techniques for maximizing the value of the requirements in your Product Backlog. This article focuses on ensuring that you have considered the full scope of potential sources for identifying what the solution needs to deliver – and equally what it should notbe delivering.
For most solutions, the requirements in the Product Backlog come from one of two primary sources: The intended end users of the solution and selected subject matter experts (SMEs). Although the input from these stakeholders provides an excellent foundation for what the solution needs to deliver, there are numerous other sources that Product Owners and Agile Business Analysts (BAs) should use to confirm, expand upon and, where needed, negate the information that these stakeholders provide:
- Managers and Executives: Although these stakeholders will rarely be the primary end users of the solution, they will often have business requirements that the operational end users will not be aware of, including management reports, executive dashboards, and notifications when project or organizational thresholds are exceeded. Equally important, these roles are often responsible for the initial – and the continued – funding of the Agile solution. It is, therefore, essential that the solution requirements factor in their expectations and their measures of success.
- Legacy System Users: If the Agile solution is replacing an existing system, the users of that system can provide a wealth of knowledge on what features were valuable (and less valuable) in the legacy system, what could be improved to better support their business needs, and what requirements were not met altogether. If the intended end users of the new solution are the same group as the legacy system users, it is often beneficial to display that system in the requirements discussions with the end users for context and memory triggers.
- Integration System Owners: If the Agile solution is intended to integrate with other systems, interviewing the owners of those system is necessary, at a minimum, to identify what data can be exchanged. These discussions can also provide a clearer understanding of data rules between the systems, including what data cannotbe exchanged. For example, the end users of the new solution may want it to produce invoices that get automatically populated in their corporate financial systems. The owners of the financial systems may, however, identify a corporate restriction that all invoices must originate from the financial systems. Knowing this up front will minimize the risk of the Agile development team building a feature that cannot be released.
- Other Technical Constraints: Similar to the integration system constraints, there may be other technical constraints on the intended platform that would make requirements identified by the end users difficult (or too costly) to implement. For example, users may identify automated payments as a critical feature in the new solution. If, however, there is no existing environment to process payments – or if the existing environment is purpose built for another solution – this feature may not be achievable. Having these technical constraints in hand will move the requirements discussions with the users to more achievable operational efficiencies that could improve payments processing.
- Organizational Policies and Regulations: Even where a technical solution may be achievable, there could be other organizational policies or regulations that restrict the ability to deliver the intended feature. For example, the end users may want to avoid excess paperwork by having all contracts be electronically signed. Corporate policy or industry regulations may require all contractual documents to have wet signatures regardless of their value. If the end users were not aware of this restriction, and if the Product Owner and Agile BA had not done the necessary research, this could be another throwaway feature for the Agile development team (or a built feature that needs to wait until these restrictions are cleared before it can be released).
- Industry Articles, Forums and Networks: Most industries have similar operational, regulatory and market requirements driving their solutions. Unless the solution that is being delivered by the Agile development team is a cutting-edge platform to address a previously unmet industry need, it is very likely that others in your industry will have already designed and built similar solutions. You can leverage their experience by researching articles in industry journals, and, if the proposed solution is not confidential, posting on industry forums or contacting your industry peers to identify what they have found to be most – or least – effective in meeting their requirements. This research may confirm the information that you have already gathered from the stakeholders. It may equally challenge it, especially where a feature that looked good on paper did not achieve the intended benefits in the live environment. It is far less expensive to learn from the mistakes made by others than to repeat them yourself.
Ideally, this article inspires you to consider other sources in your requirements investigation beyond those listed above. The goal is to empower you to bring the Agile development team a top down prioritized list of features that will deliver the most achievable, most far reaching, and most critical value to your organization.
Part Two of this series will focus on how to assign realistic values to the features on your Product Backlog.
