IIBA IIBA-AAC – Delivery horizon

1. BA Role on delivery horizon

Hello. A lot has happened since the start of this course. I have grown quite a bit. You have learned a lot about agile analysis on strategic and initiative horizons. Well done. The only remaining piece of the puzzle is the delivery horizon. How do we apply business analysis on day to day delivery of our solution? So let’s have a look.

The perfect purpose of analysis on the delivery horizon is to inform decisions regarding the delivery of the solution. We already know which problem we are trying to solve. We know the strategy, we know the roadmap, we know the scope of our solution and we know who the solution is intended for. What we need to do now is we need to make sure that we deliver it with the expected level of quality so that the expected value is realized. With that in mind, let’s review what are the expectations from a business analyst on the delivery horizon?

As a business analyst on the delivery horizon, you collaborate with your team members to ensure they get a clear and shared understanding of a need that they’re addressing. You identify and prioritize backlog of items to meet that need. You establish the means of assessing the outcomes. How can you ensure that whatever the team produces actually addresses the need and delivers the expected value? You ensure that the requirements are clearly maps to identified goals, that there is a level of traceability between the organizational goals and the requirements in your backlog.

You slice and elaborate upon the user stories to produce development rated backlog. If you don’t know what a development rated backlog is, don’t worry. We’ll talk about it in one of the next video. And finally, you perform the daily maintenance of your backlog to make sure it is too well suited to support the delivery of your product.

2. Elements of the delivery horizon

So what are the elements of the delivery horizon? The first one is ensuring the user stories are development ready. It means making sure you have enough information in your backlog items that the team can just pick them up and start delivering without the need for asking extra questions or doing extra research to understand what they need to do in order to deliver the story.

Maintain the backlog make sure that whenever decisions are made, whenever priorities are changed or any other changes happening in the world or in the business, all of this information is reflected in your backlog the moment it becomes available to you. Support the delivery function. Unblock the progress for the team and make sure they focus on delivering value. Ensure learning is happening. If the team doesn’t learn as they deliver things, next time they face the same issues, problems or challenges, they will spend the same amount of time and effort trying to overcome them.

You need to make sure that the organizational learning is happening and that the lessons learned from this delivery will be applied to the future deliveries. Finally, maintain focus on vision, customer and value. Make sure that the team delivers things that matter. Let’s have a closer look inside these elements. The first one ensuring the user stories are development ready story elaboration as a technique is used to define the detailed design and acceptance criteria for a story as needed. To deliver a working solution, a user story only needs to be ready for implementation when it will be placed into the development in the immediate future. Immediate here means that there is little chance a change will happen based on ongoing feedback and learning between the moment of time when you elaborate on the user story and the moment of time when it is likely to be picked up. Refining user stories before they are needed may cause rework and result in waste which you are trying to avoid.

A story is well written when the following is true it contains a well constructed narrative. It is easy to read. It presents a set of clear, concise and precise acceptance criteria. It’s easy to understand when the story is done. It is accepted as representing a desirable unit of implementation, meaning your stakeholders are happy with the story the way it is written.

Now it represents an achievable unit of development. It is feasible to be built in the amount of time allocated for your iteration and it is prioritized clearly in the backlog. The Next One to maintain the Backlog there are two fundamental elements to maintain in a backlog. First one, the priority should be defined for all the items in the backlog. And second, there are enough items in the backlog to support the near term delivery. Typically, you will collaborate with product owners or other business representatives and decision makers to ensure the backlog is ordered by priority.

At the same time, in order to ensure there are enough items in the backlog to support the near term development efforts. You will collaborate with stakeholders to understand which features are expected to be delivered, and you will decompose those features into user stories, which in turn will be refined into well written user stories. Support successful delivery you are expected to provide just enough information to the team so they are able to deliver valuable outcomes. This means you need to clear any roadblocks that are related to analysis and you need to apply the learning’s to avoid them in future.

This can include the following handling dependencies related to stories, coordinating with external teams and stakeholders, and finally, answering clarifying questions for items that are currently under development. You are the person who knows what the team is building, and you are the person whom the stakeholders and team members will go to if they have any questions about the scope of what is going to be built. So you need to be prepared for those questions. Next one ensure learning is happening. This may happen on two perspectives on the product perspective and on the process perspective. Let’s start with process.

On the process level, you will consider what delivery processes should be changed, kept or stopped in the next delivery cycle based on your analysis, what works and what doesn’t work? Quite often, retrospectives as a technique are used to discuss the learning from the most recent cycle. We will talk about retrospectives in one of the videos. On the product level, you need to analyze if the value delivered in the most recent increment was what was expected to be delivered. Answering this question, you may result in proposing changes to the nature of the user stories or to the priority of the user stories for the next delivery effort. Finally, maintain focus on vision, customer and value.

Retain a focus on delivering the value that is being sought and achieving the product vision. This is achieved via constant communication and maintaining a shared understanding of the need. All right, I understand this has been a lot of boring theory, and by now you’re probably wondering how am I actually going to apply this on my project? Don’t worry.

In the next couple of videos, we’re going to talk about all these little techniques and tips that will help you apply those principles and fulfill those expectations on the delivery horizon in accordance with the most common agile ways of working. But before we get there, let’s quickly talk about the time frame for planning on the delivery horizon. At the delivery horizon, planning focuses on the day to day delivery of backlog items. Agile delivery teams typically plan on a very short term basis, but what short term means will really depend on your organization and the context in which it operates. Typically, it is a rolling wave time frame of two to six weeks or one to three delivery iteration.