IIBA IIBA-AAC – Techniques on delivery horizon

1. Story elaboration and decomposition

Story Elaboration is one of the techniques that helps you ensure that your stories have enough details to be delivered. So Story Elaboration is used to define the detailed design and acceptance criteria for a story as needed to deliver a working solution. As such, it is an ongoing activity that happens throughout the delivery horizon and you reduce use wasted effort when you elaborate the stories, if you do it on just in time and just enough basis.

So you do not attempt to elaborate on the whole of the backlog at once. Rather you focus on the top priority and most important stories first. Elaborate them, make sure that the stories are good enough for the team to work on them. The team doesn’t have any questions or concerns about them and then you move on working on the next stories in the backlog. As a business analyst, you continually communicate dynamic requirements. So this requires you to have a high skill of both facilitation and communication.

You need to have communication skills so that you can present your stories to the team and stakeholders and make sure they understand what is it you’re saying. But you also need to have facilitation skills to facilitate the conversation about these stories and make sure these stories are elaborated well. So how it usually works is during each development iteration you will probably have some time scheduled for Story Elaboration activity. It may be called differently depending on your delivery methodology.

But the idea is there is a time frame when you can sit down together with your team, with subject matter experts, with customer representatives and people who are going to test this story, and developers of course to discuss these stories and make sure that the team understands what is expected to be delivered. What are the acceptance criteria for this story? They have an opportunity to ask questions and clarify things and maybe agree on some aspects of the solution design.

Eventually this story will have all the information it needs to be delivered. Sometimes the team may decide that the story is a bit too big to embrace it at once, so they may decide to decompose this story. This means to break it down into smaller independent stories that can be addressed individually on a smaller scale, therefore making them more manageable in your backlog.

Breadth before depth is one of the most common agile approaches to storage and composition. What it means is you start with understanding the whole breadth of what you are trying to deliver, probably with little level of detail for each section. Basically you define what your business goals are or maybe high level elements of your solution. As the next step, you start diving deeper into each of these goals or each of these elements, decomposing them into smaller components that provide increments of customer value.

Sometimes you may hear a term Minimal Marketable Features or MMF which stands for this smaller component within Business goal or within a part of a solution that represents an atomic feature that can be placed on the market and presented to your customers. And then a collection of these minimal marketable features will compose your MVP, the minimum viable product, or post MVP, the next version of your product.

Then, once you’ve got this, you can decompose those into your user stories. And as we discussed before, for each user story, you can take it into the elaboration session with your team to either decompose it even further to the size that can be addressed in a single iteration of your development. Or augment them with acceptance criteria to make sure that the team knows what exactly it means to deliver a particular story in your backlog every time. When you elaborate upon your user stories, it is good to have a template in mind, some formal structure that you want to get to after the end of your collaboration.

It helps to maintain a similarly looking set of stories, so it is easier for people to pick up a new story after they finish the previous one or get onboarded onto the project. At the same time, it helps you not to forget to ask certain questions or gather certain type of information for the story to be complete. A good user story template that I find really useful to use is here. So you start with a value statement. We already talked about it a little bit, so you choose the statement of your preference. It can be a user story template, a job story template, something in between, like on the screen, something that captures the idea of your user story.

What is it all about? Then? When relevant, you add a visual reference to your story. Make sure that you have a wireframe attached to it or a piece of design. If you’ve got a detailed design or a process scheme or something that helps to visualize the requirement, it is always helpful to have a visual reference to a story. People get bored reading lots of text, but they like looking at pictures and understanding the information from the pictures.

It’s much easier to communicate the information if you have a picture to illustrate it. Then you go into your acceptance criteria. The story without agreed acceptance criteria will rarely be ready to be delivered because the acceptance criteria, they scope the delivery for this story. They explain when to stop working on a story, so they help to make proper assumptions around your estimation of effort and estimation of resources needed to deliver the story.

Then you can add useful context. If a story is a part of a bigger theme, you link to this theme, or if it is a part of an epic, you mentioned it here. If a story is a result of certain activity, you also introduce this extra information to the story definition to make sure the people picking up the story they know what is the broader picture around this story. And finally you list your assumptions, especially when you estimate things. Quite often the team will assume certain things.

They may assume that they’ve got access rights, that they’ve got some other things done, that they have access to information, to systems, that some other work is already done, or that they can reuse certain things from other streams of work. There may be a lot of assumptions that the technology team may make from the technology point of view, such as which frameworks they’re going to use, which integration points they’re going to build or make available and things like that.

When you estimate the story, it’s a good idea to write down those assumptions done during the estimation process inside the story itself, so it all lists together and should any of the assumptions prove not to be true, you would have a documented reference to it and you can make it a case to reassess this story. So this is a template that I use for majority of my project. It is not taken directly from the BBC guide but I think it is good to fix it or use it and build a version of your own that you are going to use. Now let us jump back to our mirror board and see how the process of elaboration may look like. What is the flow in this session? Obviously in the real session you will have a group of people, not just me, impersonating every team member. But still, I hope we will better understand how the session flows after this small demon exercise.

So imagine you have a user story for our farming example. As a farmer in a remote area, I want to receive an SMS bill so I don’t rely on paper communications. And you present this user story to your team. The team looks at it, discusses it and may ask some questions. One of them may be what if we do not know the mobile number? So what happens in this case? How do we deliver this story if some of our users don’t have a mobile phone on record so we don’t know where to send an SMS and as a result, the team may decide to decompose this story and have two stories ready. So one of them may be as a farmer with a registered mobile number, I want to receive an SMS so I don’t rely on paper communications. Another one can talk about a farmer without a registered mobile number and this person needs to read an instruction how to register the number in their paper bill so they can register.

So the scenario is I don’t have a mobile number on record so I receive my bills in paper. And as a part of this story we want to include a paragraph of text in the paper bill how to register for receiving your bills via an SMS. You may also, through a conversation come up with extra stories such as as a farmer without a registered mobile number I want to call a support line and set up mobile number without the need to speak to a person. So it is automated and easy.

Basically what we are talking here about is you not only have the instruction in the bill but you also need to have a means for the person to act on that instruction and actually register their phone number. So this particular story suggests that the people can call a phone number with some automated responses, just type in their number on their phone and the automated IVR system will understand it and update the record on their behalf. So they don’t need to wait in line to speak to an actual person in the customer support. However, some of the people may still prefer to speak to actual customer support representatives.

So for these people we may introduce another story. As a farmer without a registered mobile number, I want to call a support line and set up mobile phone. So basically through elaboration of this story and exploring different use case scenarios, we come up with more and more potential user stories so that later someone can make a call which of these stories to prioritize? And finally, if we are talking about registering a mobile number and receiving some sensitive information that is your bills, we also may explore a user story to add a bit of security to this process. So as a farmer who tries to register the mobile number I want a way to confirm the number is actually mine. So I’m reassured no one else can intercept my bill. And this may be a solution that say an SMS confirmation comes to their number and they need to, I don’t know, hit a link or use some code from that SMS through this process to confirm that they actually own the number.

And as you go into this level of detail in your conversation, you start not decomposing these stories but augmenting these stories with acceptance criteria. So for example, we may have an acceptance criteria in here to send an SMS when the record is updated. So if a certain mobile number appears on a certain record, we send an SMS confirmation to that number to confirm that the person owning this number actually wants the number to be associated with a certain account and then this person may send a return SMS confirming it or maybe use some other tool to confirm.

In our case we’ll add a criterion that they will reply to that SMS saying like okay, I agree and finally we may have an acceptance criterion to update the record on successful response. So this user story is now enriched with three acceptance criteria. First, to send an SMS when the record is updated to the number that is associated with this record. Then to expect the return SMS from that number.

And then to finally update the record only on successful response and probably not use the phone number unless you receive a confirmation. You can also add it to your detailed acceptance criteria in your ticket. Another example of acceptance criteria can go for the automated phone line. But it’s an interesting process, right? You call a phone line, you don’t speak to a person. You speak to a robot, and that robot updates your record. So you may want to introduce certain acceptance criteria to shape this process. First, you probably need a separate option in your top level IVR menu. That’s the menu that you hear when you call an automated phone line.

Something like, press three if you want to set up an SMS billing, I don’t know, something like that. And then you need an ability to read the keyboard input during the call. So the person can just type their number using their mobile phone, using the tone keys, and then that input should be understood by the system and used to update the record. So this is your final acceptance criterion. This story is not done unless the record can be updated. So in this simple scenario, we looked at how we can take a user story, take it into the elaboration session, receive a feedback question, and based on that question, consider some extra scenarios that haven’t been considered before, and then elaborate the stories for those scenarios to some detailed acceptance criteria. So everybody is aligned on what is expected from the team to deliver a particular user story.

2. Behaviour driven development

Writing acceptance criteria may be challenging. However, it is a very important process because without those acceptance criteria, no one knows when the story is done and how to scope the delivery and acceptance of it. At the same time. Using too broad or vague acceptance criteria can get you into trouble, just like not having any acceptance criteria at all. So, to avoid the problems, an ideal story will be accompanied with a set of good concrete examples of how to demonstrate that this story is delivered in full. How do we do it? It is a collaborative process.

You do it together with your team. First, the team explores the main outline in the story and collaborates to produce some concrete examples that describe the behavior that they want to achieve. Sometimes this conversation can be really hard because it highlights all the misunderstandings and assumptions that you’d normally discover much later. But this is a good thing because it reduces rework down the track, thus it reduces waste.

Next, the team agrees on these examples as their acceptance tests for the story or their acceptance criteria. What is important is to ensure that you get the right people in the room to perform the exercise. Typically, you will have representatives of three different viewpoints on the user story. First one the business. These are some people who know the problem domain, who know the requirements. It can be the business analyst. It can be the product owner. It can be some representatives from subject matter experts or end user representatives.

Then you need the development point of view, people who are going to action on this and develop a solution. In software development world, this will be the software developers. If you are working with a design team, this may be visual and UX designers. If you are working in a more hardware world, this would be the people who are going to build the hardware. So these are the people who are going to do the work based on the requirements from the business. And finally, the testing point of view. These are the people who are going to perform the quality control on the output of the development. When these three perspectives come together, they come up with really good scenarios that can be used as very reliable acceptance criteria. This type of meeting is quite often referred to as the Three Amigos meeting three Amigos for the three perspectives who need to be friends in this conversation, collaborating to come up with good acceptance criteria.

The process I described before is the foundation of Behavior Driven Development, a software development practice that puts the creation of real business scenarios as acceptance tests before the start of development. It uses a customer readable domain specific language to specify the intended customer behavior which satisfies the customer need. As such, it increases the speed of delivery by developing only what is needed and creates an opportunity for user acceptance. Test Automation there are a variety of software solutions that can be used alongside the BDD development process to help with this automation. They all have one scene in common the very specific syntax that you use for writing your acceptance test. Let’s talk about it in the next few.