So, you have defined your product vision. You have gained approval to proceed with refining what the product should be. In other words, you will be determining what the requirements should be. In scrum terms that means creating the Product Backlog. Officially, the Product Backlog is a prioritized list of all the known requirements, desires, wishes, or glimmers to be included in the product. It is ever changing and never complete. That is it and it pretty simple. The Scrum Guide covers the Product Backlog in about a page of text. Compare this to the hundreds of pages that the Project Management Institute (PMI) devotes to the topic of requirements.
This is great, it seems so simple, a vision of what you want to build and a list of stuff that is needed to achieve that vision. As the saying goes, the devil is in the details, and in a Product Backlog of any level of complexity, there are a lot of details and a lot of devils.
Product Vision to a Product Backlog
How you fill the Product Backlog is one of those areas where Scrum is, regrettably, “silent”. There are a lot of approaches on the Internet and plenty of commercial tools on the market, of varying degrees of quality and effeteness. Lamentably, there is nothing definitive. So, what is a soul, or product owner, to do? Just make stuff up that you think might be useful.
Let us think about what an Agile requirements management (or Scope Management to use the name of the Knowledge Area from the Project Management Institute) should do. Can we break the overall process down into a series of repeatable steps? Can these steps be designed to be iterative such that the requirements emerge as we repeat the steps? Can the method be designed so that it focuses on producing the greatest detail for the highest value requirements, first?
Answering these questions in the positive will be critical to making sure we flesh out the important requirements in a transparent framework. Such a procedure will allow us to inspect and adapt, not only the requirements themselves, but the process by which they are created.
Stepping Right Up to the Vision
Let’s start off with a tightly organized framework that borrows a lot of detailed analysis methods from PMI knowledge areas, while insuring that we maintain agile structure and flexibility. We recommend starting with the straight forward simple 7 step procedure:
- Develop and refine a solid Product Vision:
Develop a Product Vision and understand it as completely and broadly as possible. See the PointProx article on how to create a good Product Vision. - Begin requirements gathering to determine items that meet the Product Vision:
This is potentially a large effort. PMI’s analogous Scope Management devotes hundreds of pages to the discipline in its PMBOK Guide, Requirements Management Practice Standard, and Software Extension to the PMBOK Guide. Even though there are significant differences between PMI and Scrum, much of the information found in the PMI documents can apply to the Scrum as well. All in all, PMI Scope Management is not a bad place to start. It provides guidance, tools, and techniques on how to ascertain what is anticipated to be in the product. Portions of the practices are for determining what to exclude from scope. Since Scrum uses prioritization and value assessment to determine what to build, the scope excluding potions of PMI Scope Management are of less importance on an Agile undertaking. - Create an empirical analysis process control:
Create a process control to refine gathering of requirements. Utilizing the three pillars of scrum empiricism, that is: Transparency, Inspection, and Adaptation on the requirements gathering process will result in Product Backlog Items that are better aligned to the Product Vision and have a greater potential to provide true value to the product. This needs to be a continuous practice so that requirements gathering becomes increasingly more effective and efficient throughout the life of the project. - Allow the product to emerge over time:
One of the frequent complaints about the classic PMI Scope Management, when used for software development, is that it can be rigid. Early concepts of detailed requirements become so locked into the design that the product has trouble adapting as practical feedback is acquired. Even if initial conceptions are wrong, it is hard to change ingrained patterns established early in the definition of what the detailed finished product should be. Preliminary ideas develop inertia in the project as so many subsequent decisions become based on them. The Scrum framework is designed to emerge the product through a flexible process that changes as the product is created. The PMI approach is designed to determine and plan as much as possible in advance of starting to build. - Determine and set stakeholder priorities and order the Product Backlog accordingly:
Determining stakeholders, requirements, and priorities are separated when we discuss methodologies in an academic forum such as this article. In actual practice, these disciplines are generally melded together. As a Product Owner or Project Manager one of the first things that needs to be done is to evaluate stakeholders. Typically, this will mean prospective stakeholders will be interviewed to ascertain their expectations for the product to be yielded by the project. Stakeholders will likely discuss the relative importance of the features of the product and product vision. This is an extension of the exploratory activity undertaken as part of creating the product vision. These three work streams: stakeholders analysis, requirements emanation, and priority rating, will result in list of prioritized Product Backlog Items (PBI). - Build methods to iterate through requirements:
Instantiate methods to iterate through the individual requirements to provide detail and comprehension sufficient to begin development. The idea is to focus on the highest priority PBIs first. Expend the most work on the requirements that are closest to being assigned to a sprint. It is important to attempt to break down larger requirements into smaller pieces. Generally, ++size == ++risk. The bigger a requirement, the greater the chance it is not completely understood the greater the chance it will not be done correctly. Corollary to the above, the larger the requirement, the larger the investment of time and effort on the part of the project team, and therefore the larger the impact of getting it wrong. - Start again from the top:
Remember that Scrum is an iterative framework that increases the quality of the product through continuous refinement. This thinking applies to gathering requirements as well building functionality.
What’s it All Mean
Each of the 7 steps could be an article in and of itself. The tools and thought processes can be complex and we will endeavor to address some of the more interesting elements in later posts. However, the above is sufficiently detailed and comprehensive enough to get started. The flow provides a good framework that can be adjusted, as needed, as you work through the project.
If you want to get a head start on the Agile Requirements process, go through the PMI documents related to this practice; especially the Software Extension of PMBOK and the PMI Requirements Management Practice Guide. Both are excellent resources that help to fill in the areas where Scrum is “silent”. Understand what the guides are recommending and then adapt them to your Agile practices. Keep in mind the three pillars of Scrum empiricism and use them to adjust both the requirements and the way that these requirements are discovered, refined, and validated. Merging these two approaches will give you the benefit of a mature detailed methodology (PMI) with a flexible, low risk, and adaptable structure (Scrum). It will result in a good start on the “best of all possible worlds”.
References
- Project Management Institute: Software Extension to the PMBOK Guide Fifth Edition
- Ken Schwaber: Agile Project Management with Scrum
- Ikujiro Nonaka and Hirotaka Takeuchi: The Knowledge-Creating Company
- Project Management Institute: Requirements Management: A Practice Guide
- Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Sixth Edition
Leave a Reply