IIBA IIBA-AAC – Techniques on delivery horizon Part 4

5. Agile ceremonies

Delivery evolves around a set of routinely repeated ceremonies. A ceremony is a timeboxed activity with a clear goal that happens in cycles. Again and again, think about it as of a recurring meeting with set agenda and process. Depending on your delivery methodology, a set of ceremonies may be very different. For example, this crumb process will require a different set of meetings compared to say, DSM process.

This is the reason the BBA Guide and the Agile Extension, the BBC Guide, do not focus specifically on different ceremonies, as both books are meant to be implementation methodology agnostic in its nature. However, a lot of the guiding principles from the Be Able Guide and from the Agile Extension to Be Able Guide are applied to the typical Agile ceremonies. So in this video, let’s review some of the most popular ceremonies and activities that you as a BA are likely to participate on a typical Agile project and then we’ll see what is the expectation of a BA in those meetings and what are the typical responsibilities of a business analyst inside them.

The first activity here is backlog ruman. Unlike others, this one is not a timebox meeting, but rather an ongoing process. But guide does not separately define a crewman, ceremony or activity. It talks, however, about a backlog refinement as a continuous process. In reality, it is beneficial to understand the difference between all the ongoing preparation and maintenance of your backlog. This is what I call grooming here and a structured timebox session with the team.

That is what I call refinement session. In this course, once again be able to guide or specifically Agile Extension to be able to guide call them both backlog refinement. But again, in practice you will probably address it a bit differently when it is an ongoing thing and when it is a timebox exercise with your team members. So, talking about the backlog rum and the goal is to make sure that your backlog is aligned with the product vision and you do it on your own altogether, with the product owner or with some other key stakeholders.

Typically, your role will involve the following you work with your stakeholders to arrange the backlog so it reflects the product’s vision and is ready for refinement with the team. You don’t want to go into refinement session not having any backlog in place. You need to prepare your backlog to make the refinement session effective and efficient. You add details to these stories during this session or you plan the elaboration of these stories and then you execute it when you sit down with your team. Finally, your ultimate goal is to get ready for refinement session.

You make your backlog neat enough for the rest of the team to start looking at it, make sense of it and be productive in discussing the stories and elaborating upon them. This leads us into the backlog refinement session. You have your backlog ready and groomed to a state when it is ready to be presented to your team. You gather your team together and you start presenting the backlog, effectively performing the decomposition and elaboration techniques. So the goal of your backlog requirement session is to familiarize the team with the backlog items, answer the questions, get estimations, and make sure that your backlog items reach your definition of ready. Who is involved in this meeting? Well, typically it is the team, sometimes the product owner, sometimes some stakeholders that may have their say in the session.

Your role in this session is to present the backlog and the user stories in details to your team to answer the questions that they may have, or redirect the questions to the people who may have the answers. Narrow down the questions that you need to clarify after these sessions, or maybe use spikes to document them, facilitate the estimation of these stories and update the user stories as you go.

You add the estimations, you add the assumptions made during these sessions, and you also add the uncovered details to these stories so they are not forgotten later when these stories are picked up for delivery. So once again, for the purposes of IABA Agile Analysis Exam, they talk about refinement as an ongoing activity to maintain and enhance the backlog. In practice, part of this activity you will do on your own as a part of ongoing backlog grooming, talking to individual stakeholders or working together with the product management or product owner.

Part of this activity will happen together with the whole team in a much more structured and most likely timebox manner. This will be the backlog refinement session. There are a couple of definitions closely aligned to backlog refinement and grooming activities that you need to know. The first definition is the definition of ready. It is a set of criteria that the team agrees must be satisfied to consider an item ready for the next iteration.

Another definition is the definition of done. It is a set of criteria which must be met before a backlog item is considered done. So effectively, your definition of ready is your entry criteria into the development workflow. If a backlog item does not satisfy the definition of ready, it cannot be picked up by the delivery team for development.

Definition of done is your exit criteria from the development workflow. If the definition of done is satisfied, it means your delivery team has done their job and the item can be shipped to production or to the customers. If your definition of done is not met, it means there is still some efforts to be applied on this item to get it to the definition of done and to call it closed.

You cannot close a backlog item if it hasn’t reached the definition of done. So typically these definitions, they are agreed with your team and your stakeholders early on your project, ideally before the start of first development and delivery sprint. Because these definitions really guide your grooming and refinement sessions and your estimations and then they guide your acceptance for the backlog items.

So it is really important that you facilitate your team into getting this definition written down and agreed and then shared with all the stakeholders. So everybody knows what are the entry criteria into your development and what are the exit criteria after your development is finished. The next ceremony that we are going to talk about is Sprint planning or iteration planning. It is an extremely popular task that NHL team performs and business analysts will participate in it. If your team runs Scrum or similar process, you will have to participate in Sprint planning very, very often. So you need to be prepared often. Iteration planning will include elements of story elaboration and backlog refinement. So all the techniques that we discussed when talking about those two activities will still be applied here. The goal of screen planning is to plan the next delivery iteration, which raises a logical question what is an iteration? Let’s have a look. The Agile extension to be a guard says that an iteration is a defined time period. When increments of a product are developed and tested and made ready to deliver to the customer, it may be of any time length.

Typically, majority of projects will stick to somewhere between two and six weeks of time for individual iteration or Sprint. And each iteration when it is defined will always be timeboxed to the same length. You never change the duration of your iteration once it is defined. So coming back to the Sprint planning or iteration planning with the goal to plan for the next delivery iteration, you involve the whole team. Everybody in the delivery team, including the product owner, will be typically involved in this planning.

The way the meeting runs conceptually is that product owner or someone who understands the business priorities will list the list of priorities for the next iteration given and ask to the team. Please address these priorities. And the team will look at its own capacity to deliver work or its own velocity, how many of estimated points they can deliver within iteration. And then they will look at the scope of the backlog items related to those high priority items.

And then they will commit to some work that will aim to address the needs of the business within the next iteration. So what is the typical beer role in this process? You will present the backlog and the user stories to the team. You will facilitate the estimation if the stories are not estimated yet or if they need to be reestimated. After some conversations that happen in the meeting, you will update the stories.

You will add estimates, assumptions, uncovered details just like you would do during any refinement session. And you will make sure that the team is comfortable with the scope that they commit to. At the same time, you need to make sure that whatever the team commits to is still relevant for the business priorities is still going to deliver on the business priority for the next iteration.

And you will need to apply your mastery in communication and facilitation to make sure that the product owner and the team agree on the scope that is feasible to implement and that is viable for the business. The next HL ceremony that we are going to talk about is Sprint Review.

The idea behind Sprint Review is pretty simple. During your Sprint planning, you plan the work for the next iteration and when the iteration is finished, you review the work that has been done and collect any outstanding work. You make sure that all your tickets are done in full and if they are not, you need to ensure that the team understands what is the outstanding task.

So typically the whole team is involved in this exercise and it is important to make sure that there is a person in the room with decision making authority, be it product owner or product manager or someone else in the team who is empowered to make decisions about this scope. The B’s role typically is about documenting the outstanding work in the tickets that are not done and updating the backlog based on any team decisions to unblock their further progress.

Typically, when you conduct such a meeting, there are a couple of potential use cases. First, all your tickets may be done and you just close this print. That’s easy. But quite often not all the items are done in full and there may be some outstanding bugs or defects or h cases that have been uncovered during this print. Typically, the most heated conversations are around those. What do you do with bugs found during this print?

Do you still call the tickets not done until all of the bugs are closed or do you still close them or not? So quite often it is a decision that sits with your product owner and there are a couple of options. One option is you never close the stories if there are some outstanding bugs associated with them and you just say that this story hasn’t been done in this Sprint, so it rolls over to the next one. Or another approach would be to record the outstanding defects and new newly found cases as separate backlog items so that the existing story can still be closed as long as the acceptance criteria are met. However, there will be items in your backlog to revisit the same functionality in the future and make it even better. Another activity associated with the end of the Sprint is Sprint Showcase.

The Sprint Showcase is a way to celebrate the end of the Sprint by presenting the results of it to a wider group of stakeholders and interested parties. So the whole team usually plays part in this exercise. Plus the team invites a lot of people to show what has been done. This is an opportunity to show the progress to the stakeholders and also to collect some early feedback from them. There is typically no specific role for a business analyst in this meeting. A business analyst can present at one of the showcases, just like the rest of the team may do.

The last type of ceremonies that we are going to talk about today is Retrospective. The goal of Retrospective is to reflect on the previous iteration and discuss opportunities for improvement. That is why, in my personal opinion, it is one of the most important ceremonies in the AGL process because it fosters the continuous improvement. Unlike Sprint review, retrospective does not focus on the scope of what has been delivered in the previous iteration.

It focuses on the process of how things have been delivered instead. So the whole team is involved in this exercise. And quite often this exercise requires a safe space so no external people are allowed to be a part of Retrospective. It is a place for the team to be honest with each other. The B’s role during the retrospective is just the role of any other team member to contribute to the conversation and suggest ideas. You can also use your B skill set in a process improvement area to suggest some activities for process improvement or propose some other enhancements to how the team works together and how they are delivering the product.

There are many ways how a retrospective can be run. Some teams prefer to do them in really fun and engaging ways, while others convert it into a really serious and thorough process improvement exercise. Regardless of which way of retrospective your team chooses, the goal of this exercise is to get insights from your team of how to make the delivery of the next increment better. And a really great technique that may help with that is to use the Norman Kerrs for questions. Norman Kerr is the person who is often called the father of Retrospectives. He was one of the project managers who was advocating for running Retrospective after each project that you run, to learn and to become better.

So the four questions read as following the first one what did we do? Well, that if we don’t discuss, we might forget. The second question what did we learn? The third question what should we do differently next time? And the final question what still puzzles us? At a bare minimum, if you make your team answer these four simple questions at the end of every iteration, you will collect enough insights and ideas to make each further iteration better and better, thus applying the genius improvement.

6. Mapping the principles on delivery horizon

It’s about time we review how the principles of Agile analysis can be applied to delivery horizon. The first one see the whole you need to develop a shared understanding of how individual stories advance outcomes. Make sure that you find a way to measure the progress against your goals and that each item is prioritized to achieve the overall goal. Think as customer.

Define who the customer is for each story in your backlog and align the value delivered within that story to the customer experience. Also consider how the processes and products that you are delivering meet the needs of your customers. The Next one analyze to determine what is valuable. Refine the backlog based on the feedback and learnings. Consider other external factors that may impact the creation of your value, such as team happiness or defects, rate or velocity, or quality of improvements that you make along the way.

Get real using Examples Use examples when refining your stories and writing acceptance criteria. Especially, make sure that those scenarios and examples are aligned with customer experience that you are trying to deliver. The next one understand what is doable Consider things like needs, expected outcomes, constraints and risks to refine these stories and make sure you set the expectations of what can be accomplished with your stakeholders. Similar collaboration and continuous improvement Encourage close collaboration with your team, such as techniques like Three Amigos meetings or BDD practices. Leverage the strengths of your cross functional team. Finally, avoid waste. Focus on the stories that deliver maximum value first. Also, try to maximize work not done, which means you avoid doing things that are not necessary to deliver your value.