Planning for Requirements in Agile – How is it different from Waterfall?
Many teams struggle with their requirements approach, but it’s especially challenging for teams transitioning from waterfall to agile.
If the team neglected requirements planning in waterfall, they assume agile requires even less planning. This leads to even worse results than their traditional approach, and the agile transition fails.
If the team planned well in waterfall, then they struggle with agile’s iterations and timelines. They aren’t sure how to plan requirements without structured waterfall phases. Lacking an alternative, most teams default to their old approach by focusing on document deliverables, activities and time needed from stakeholders. But that document deliverable-based approach, conflicts strongly with agile values. Agile values focus on deliverables being defined as business outcomes and working software, rather than document based deliverables.
Agile calls business analysts to shift their thinking about requirements planning. Instead of focusing on document deliverables, agile BAs plan their approach by defining and prioritizing increments of value; or increments that move outcomes. They determine which increments provide the most value and in what order. Increments of value come in many shapes and sizes including things like fixing a defect, running an experiment, building a slice of a prototype, or a user story at various levels of detail.
In both approaches, best practices call for multiple levels of planning where teams decompose requirements from a high level to detailed levels. Since many of you are familiar with the BABOK v3, let’s use it as our guide for planning. Here’s how the BABOK’s BA planning tasks manifest themselves in an agile approach:
Plan Business Analysis Approach: choosing methodology, activities, tasks and deliverables.
This is where agile values can really shine! Not all projects fit the agile approach, but increasing complexity, ambiguity, and market volatility push teams to use an agile approach more frequently.
When using agile, your BA work focuses continually on priorities and backlog refinement. This is not a task or phase that is “one and done”—planning is ongoing. In fact, agile teams and BAs plan to re-plan!
Agile BAs evaluate priorities holistically. They look at the priorities and ask themselves:
- How do these priorities align to delight the end user?
- How do these priorities align with strategic objectives?
- Can these priorities be chunked into smaller increments of value?
- Does the entire feature need to be built or can the team define incremental and usable versions of the feature?
- Where does each new increment rank in priority compared to the other items on the backlog?
Agile planning is about getting quick feedback from users to inform decisions on the next level of planning and establish priorities. Agile BAs work closely with the product owner to track the visions and direction of the solution, to understand high level priorities, and to break down priorities into smaller pieces that can be delivered quickly to get user feedback.
Plan Stakeholder Engagement: identifying and collaborating with stakeholders.
Here BAs work closely with the product owner to determine who the various stakeholders are and how the team will interact with them.
Using the product vision, roadmap and backlog as a guide, BAs can determine:
- who the important stakeholders are
- when we expect to need time from them
- how much time we need to work with them on story refinement
- how and when to get feedback on the solution as it gets built
When requirements planning is ongoing, BAs continuously work on the backlog. They understand what is in the short-, mid- and long-term so they can anticipate when stakeholders are needed. Some stakeholders will interact regularly and some less frequently with an agile team.
Plan Business Analysis Governance: making good, consistent decisions while managing resources and risks.
When teams truly embrace the agile principles, there is actually more governance than you see in many waterfall or traditional approaches.
Why is this? Because there is a clear decision-making process and a clear role accountable for the decisions. In agile business analysis, this means knowing who the product owner is, and working closely with them as the decision maker. It entails helping the product owner understand when certain decisions are critical and ensuring they have the needed information to make them.
Plan Business Analysis Information Management: how to capture, store and integrate information gathered by business analysts.
Traditional projects teams capture and store requirements in documents and requirements tools. Agile teams can also use tools, but they tend to rely more on whiteboards, walls, flipcharts and sticky notes to capture and store requirements. With agile teams there is a lot less work in progress, so there is less to manage at a detailed documentation level.
The key in agile is for everyone to understand the big picture vision of where the solution is headed, and the details of what is currently being worked on. Agile calls us to think about what we are documenting. BAs on agile teams always ask themselves:
- Is this documentation valuable and useful?
- Who does this documentation provide value to?
- When is the documentation needed?
- How long will the documentation provide value?
One thing I commonly see teams concerned about is the life of the requirements. They hesitate to move away from big requirements documents because flip charts and sticky notes don’t seem like legitimate artifacts for future reference and support. I struggle with this because I have never seen it to be a good practice to use requirements documents as support documentation. This puts an undue burden on the requirements process and slows it down. Documentation of what was built and how it will be used is not the same as requirements. These are different artifacts and different purposes.
Identify Business Analysis Performance Improvements: managing and monitoring business analysis work for continuous improvement.
This is the “monitoring task” in the BABOK rather than a planning task. Agile teams use retrospectives to improve performance. The retrospectives facilitate continuous improvements in:
- team processes
- team collaboration
- the quality of team and individual work
Whether you use the BABOK as a guide for requirements planning or take your own approach, remember that balance is the key. Avoid diving recklessly into the action without a plan, but don’t let planning be a burden that prevents progress. Whether your team is agile or traditional, find the balance that consistently and efficiently delivers value to your end users
