6. Delivery Horizon
6.4 Time Frames
Agile Extension to the BABOK® Guide
At the Delivery Horizon, planning focuses on the day-to-day delivery of backlog items. Agile delivery teams plan on a very short-term basis. What short-term means depends on the organization and the context in which it is operating. As a general reference, the Delivery Horizon guides analysis and action over the period of the upcoming one to four weeks to as long as six to eight weeks. In an agile context, this time frame continually shifts and moves forward, creating what can be considered a rolling time frame.
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
