Getting Agile requirements right can be a challenge but it’s essential as they can make or break your product. Without the proper planning, you could end up missing deadlines, going over your budget, and releasing an obsolete or even nonviable solution.
Excella has put together a visual guide that should help you, your colleagues, and your stakeholders avoid many of these worst-case scenarios.
What is Process vs Scope?
The Process infographic above shows how your team will operate once everything is ready and a budget is approved. But you can’t start until you know the size of the investment you’re willing to make. The Scope infographic outlines that process. To succeed with an Agile effort, you need to know how much funding you will have and whether it will deliver the value you have in mind.
How does the Process Begin?
The scope begins with a business idea or customer need. This can take any form, but it often comes down to an enhancement that helps improve your product for the end-user.
The next step is impact mapping, to determine how to alter the behavior of users and identify how the team can create the desired impact. This is a key step that can expose hidden assumptions or misconceptions and allow the team to learn new, additional information. Impact mapping often leads to a better understanding of how to approach problems and create solutions.
After impact mapping, you can create a prioritized list of needs. Generally, prioritization balances importance to the business and ability to deliver in a timely manner. There are many valuable approaches to prioritization; when selecting one, make sure to keep speed of decision-making in mind.
The ability to commit financial resources is critical. To effectively execute the anticipated scope, key stakeholders need to request and approve the necessary funding.
Are All Steps Important?
Yes! All steps in the process are important. Skipping or glossing over steps can lead to undesirable outcomes. If you’re going to try to build products in an Agile environment, you need to make sure you are committed 100%.
To ensure that you stay on track, you should identify someone to be the Product Owner. This person should have:
- Accountability for success
- Authority to make decisions
- Ability to move the implementation forward
The Product Owner is responsible for crafting a product vision. The product vision is essential because it provides a holistic understanding of what the product will accomplish for relevant stakeholders. A useful approach to refining a product vision is to put yourself in the shoes of a customer. When they have a question, how do they answer it? What steps do they take? What impediments do they encounter? Once you gain an understanding of their perspective, you will be better equipped to build and provide solutions that help improve their lives.
It’s also important to form an effective development team. Cross-functional teams are best. They have team members with a variety of different and complementary skills so that by working together, they can solve almost any problem, even unanticipated ones.
Once you have the team in place, you can proceed to Progressive Elaboration. When done well, this approach will provide a functioning product to your stakeholders as quickly as possible. From there, you will present a steady and consistent stream of timely improvements and enhancements, progressively moving towards the desired value.
The Product Roadmap indicates what we would like to see in the product at specific times in the future. This communicates our plan to stakeholders. Like any strategic planning document, the Product Roadmap needs to be flexible so that we can take advantage of unexpected opportunities, but it gives you a plan that you can work towards as new requests and recommendations emerge. It can also be a useful tool to limit scope creep.
The Product Backlog contains various items that meet the needs of, or have been requested by, end-users. You can use the product roadmap to help identify which features are most critical and their relative priority.
Some of the items in the Product Backlog will be user stories. These can take several forms. A common one is, “As a [type of user], I want [functionality] in order to [statement of value].” This helps explain the outcome desired, rather than the specific functionality that might deliver it. It orients team members to the mindset of end-users and helps provide a customer-centric focus.
With a backlog in place, the team can start iterating. During Iteration Planning the development team meets and plans the work that will be performed within the upcoming iteration; their output is an Iteration Backlog, a specific set of items, pulled from the Product Backlog, that are planned to be delivered in the upcoming iteration. Over the course of the iteration, the development team implements new product features. The goal is to achieve a specific set of iteration goals (often only one) that provide a theme for the iteration. The items on the Iteration Backlog should be aligned towards this goal. Specific stories or work items are only accepted as “done” if they are potentially shippable to the client and available to be used in the Product. At the end of the Iteration, or perhaps continuously within it, the updated Product is released.
Users are then able to use the updated version of the product and its new features. By observing their behavior, we can identify new product improvement ideas or business needs.
This is not a theoretical approach. Those of us at Excella have consistently used this approach with our clients to deliver many successful product development efforts.