6. Delivery Horizon
6.6 Applying the Principles of Agile Analysis at the Delivery Horizon of Planning
Agile Extension to the BABOK® Guide
6.6.1 See the Whole
At the Delivery Horizon, the agile principle of See the Whole is applied when there is a shared understanding of how individual stories advance the business outcomes and value is created, and there is a means to measure progress against desired goals. Business analysis practitioners ensure that each item in the backlog is prioritized and sequenced in order to contribute to the overall goal of the solution.
During reviews and retrospectives, recommendations for improvement are assessed to determine if they have a positive impact on the overall delivery of the solution.
At the Delivery Horizon, the agile principle of Think as a Customer is applied when business analysis practitioners align the value being delivered to the customer experiences learned from feedback.
Business analysis practitioners continually consider how both processes and products delivered meet the needs of the customer. Personas (or roles) are frequently used to model and understand customer needs and experiences.
By remaining conscious of who the customer is for each story, and whether or not they would genuinely experience a benefit from the delivery of that story, the business analysis practitioner helps to prioritize items that the customer finds valuable. This contributes to the delivery of the greatest value possible in the shortest time possible.
At the Delivery Horizon, the agile principle of Analyze to Determine What is Valuable is applied when continuous feedback and learning is used to maintain the backlog. Business analysis practitioners collaborate with stakeholders to achieve a shared understanding of what is valuable and who derives that value for each story.
Business analysis practitioners analyze what is valuable from both a product and process perspective. From the product perspective, the analysis of feedback and learning guides decisions on maintaining the backlog and refining stories. From the process perspective, consideration is given to what impacts the creation of value:
- Is the team happier?
- Are defects or impediments being reduced?
- Is velocity increased?
- What is the expected benefit of a proposed improvement, and which one might be most important to the team?
At the Delivery Horizon, the agile principle of Get Real Using Examples is applied when examples are used to collaborate when prioritizing stories in the backlog and when creating clear, meaningful acceptance criteria.
Business analysis practitioners use examples to clarify the experience of the customer as they use the story or feature being analyzed.
Examples of specific situations and impacts promote a shared understanding of proposed process improvements and provide clarity when making decisions regarding process improvements.
At the Delivery Horizon, the agile principle of Understand What is Doable is applied when need, outcome, constraints, and risks are used to refine and prioritize user stories.
Business analysis practitioners consider their current and evolving understanding of the context to collaborate with stakeholders to achieve a common understanding of what stories or process improvements can actually be accomplished and which ones are not realistically achievable.
At the Delivery Horizon, the agile principle of Stimulate Collaboration and Continuous Improvement is applied when delivery teams collaborate on analysis and delivery activities as part of their daily work efforts, and during structure review sessions such as reviews and retrospectives.
Collaboration and continuous improvement is a central paradigm in agile business analysis. Business analysis practitioners seek to collaborate and continuously improve in every activity and every interaction with a view to leveraging the variety of strengths present on cross-functional agile teams.
Business analysis practitioners use their skills in problem definition, facilitation, and solution exploration to support process improvement in the delivery of the solution.
One of the ways that business analysis practitioners avoid waste is by maximizing the work not done. Directing efforts to the stories that deliver maximum value reduces the efforts directed to activities that do not add the most value to the solution.
Mapped Tasks From the BABOK Guide
Learn how Tasks from the BABOK Guide Knowledge Areas apply at the Delivery Horizon.
3.1 Plan Business Analysis Approach
At the Delivery Horizon, the team plans the best way – most rapid, efficient, or accurate – to decompose features to stories for the immediate work effort, and in alignment with the team priorities and context.
The agile approaches and activities are continually redefined and business analysis methods change and evolve as feedback is received.
3.2 Plan Stakeholder Engagement
The plans for stakeholder engagement are relative to the specific needs of the Delivery Horizon.
The approach for establishing and maintaining effective working relationships with the stakeholders is an ongoing adaptive process and includes stakeholders from across all initiatives in the organization who have direct interaction with the solution and provide in-depth andd etailed feedback regarding the solution.
3.3 Plan Business Analysis Governance
The delivery team defines what business analysis governance is needed to define decisions for requirements. This includes how refinement will happen, what information radiators are needed for stakeholders, and how changes will be communicated within the team.
3.4 Plan Business Analysis Information Management
The approach for how business analysis information will be stored and accessed is defined through ongoing collaboration within the delivery team. To facilitate continuous improvements, feedback and learning is shared with the other horizons.
3.5 Identify Business Analysis Performance Improvements
Business analysis practitioners consider improvements that can be made to ongoing analysis activities. Speed and accuracy become very important in analysis practiced at the Delivery Horizon, and any process improvements that are identified are considered for implementation.
Assessing business analysis work and planning to improve processes is continuous and based on ongoing feedback. Measures focus on the ability to learn and adapt based on ongoing feedback.
4.1 Prepare for Elicitation
Preparing for elicitation considers what kinds of elicitation are necessary: decomposing features to stories? Reviewing stories? Elaborating on features already underway? Each may require different preparation.
4.2 Conduct Elicitation
Conducting elicitation may take different forms at the Delivery Horizon. Communication may be casual or formal, consistent or sporadic, but it is always continuous.
4.3 Confirm Elicitation Results
Confirming elicitation results may be specific to reviewing a discussion or communication, but may also be done as the review and approval of user stories for implementation.
4.4 Communicate Business Analysis Information
At the Delivery Horizon, communicating business analysis information includes communicating cross-team dependencies and discussing priorities with stakeholders. Context and analysis models help communicate how backlog items align to the desired outcome.
4.5 Manage Stakeholder Collaboration
Driving collaboration and connection is a core agile value, and a core agile business analysis value. Business analysis practitioners find ways to ensure that activities are transparent and communicated.
5.1 Trace Requirements
Stories are traced to features, which may in turn be traced to the desired outcomes. Additional tracings may be made to business goals, users affected, and any number of metrics.
Efforts focus on aligning backlog items and requirements to the product roadmap and goals.
5.2 Maintain Requirements
User stories and features are monitored for staleness. As time passes, it is likely that the business need, business environment, technical environment, or customer need will have changed. User stories may need to be revised, re- prioritized, or removed.
5.3 Prioritize Requirements
At the Delivery Horizon there is frequent change to the prioritization of backlog items as learning occurs from delivered stories and completed features.
5.4 Assess Requirements Changes
User stories and features are monitored for staleness. As time passes, it is likely that the business need, business environment, technical environment, or customer need will have changed. User stories may need to be revised, re-prioritized, or removed.
5.5 Approve Requirements
The creator of an artifact or deliverable has their work approved by someone other than themselves, preferably someone with a view of the desired value being delivered. User stories and any supporting documents are frequently approved by the business owner in this task.
6.1 Analyze Current State
Collaborating with the product owner and others, business analysis practitioners examine a specific portion of the current solution. Care is given to keep scope focused on those things that will be immediately affected, given the nature of the Delivery Horizon.
6.2 Define Future State
The immediate future state is considered and defined, focusing on the value that will be delivered in the upcoming delivery cycle. Current work is assessed to ensure it aligns to the desired outcomes of the initiative.
6.3 Assess Risks
Business analysis practitioners consider what could go well, poorly, and what could influence the work and the value being delivered.
6.4 Define Change Strategy
Change strategy is lightweight and is done at the completion of each delivery release. When a set of requirements for a product or service is released to stakeholders, the team elicits feedback to understand if the requirements met the need and solved the problem.
Based on this feedback, the team can make any necessary changes to the backlog.
7.1 Specify and Model Requirements
The Delivery Horizon specifies and models requirements in the form of lightweight documentation such as user stories, job stories, wireframes, or product backlog items.
7.2 Verify Requirements
Requirements meet quality needed if the delivery team can clearly understand, collaborate to deliver, and validate requirements.
Verifying is a lightweight activity that demonstrates team agreement.
7.3 Validate Requirements
All requirements are validated against the need with the solution is delivered.
This can be automated through Behaviour Driven Development or manual through user acceptance testing.
7.4 Define Requirements Architecture
Business analysis practitioners collaborate with the delivery team to decide on the form of user stories as well as what other supporting artifacts will be used.
Requirements may include necessary metadata such as traceability to features, metrics, and other sources.
7.5 Define Design Options
Design options are evaluated and selected, collaboratively and with input from team members and stakeholders. A user story narrative form will frequently leave the greatest possible room for the design to fulfill the requirements. The actual form of those may be decided on or altered at the last responsible moment, which may be within the time frame of the Delivery Horizon.
7.6 Analyze Potential Value and Recommend Solution
Collaboration, feedback, and learning are used to select solution options or make decisions with key stakeholders such as the product owner.
8.1 Measure Solution Performance
Implemented stories should be altering solution performance, either individually or as they accumulate. Stories have the expectation that they will move one or more metrics in a known direction. That expectation may or may not be fulfilled; this becomes an important source of learning and feedback.
8.2 Analyze Performance Measures
Analyzing performance measures at the Delivery Horizon will help inform the decision of whether to continue, discontinue, or change the stories currently in the backlog. For example, once sufficient beneficial change has been achieved that is related to a particular feature, the team may choose to work on a different feature.
8.3 Assess Solution Limitations
The purpose is to identify any limitations that would affect the delivery options. For example, a team should identify any infrastructure limitations to the intended solution.
This is lightweight and focusing on what is known now and what is needed now for delivery.
8.5 Recommend Actions to Increase Solution Value
This activity is of high priority at the Delivery Horizon. A subtle difference in implemented stories is where value can be enhanced or diminished. Learning and feedback about implementations and metrics will drive this activity.
Delivery Horizon Techniques
Agile Extension
BABOK® Guide
