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.4  Assess Enterprise Limitations

This task is not completed in the Delivery Horizon.

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.