IIBA IIBA-AAC – Techniques on initiative horizon Part 2

5. Prioritisation frameworks

As you see, using story maps or managing the backlog in general always assumes understanding the relative priority of different elements of your backlog. In this section, we’ll talk about different tools that will help you prioritize your items in the backlog. A prioritization framework is a tool to help decide which items are more important than the others. It can be used in various situations when there are difficult choices to be made, multivariate to choose from, or competing interests.

Being a structured tool, it assists in looking at problem in a new way and brings new perspective to the table. The gel extension of the BBC guide features two techniques that may help with Fertilization. One is called purpose alignment model. Another one is called Cannot analysis. The Purpose Alignment Model assesses the features on two axes market differentiation and mission criticality. Depending on the score, each featured service gets on each axis from low to high.

The feature gets into one of the quadrants. The first quadrant, the differentiating quadrant includes features, products or services that help differentiate the organization in the marketplace and are critical to that company’s mission. Organizations prepare to invest in this to get their competitive advantage and get better than the competition. The next quadrant is called Parity Quadrant. Items here aren’t mission critical, but they are standard in the industry, such as finance, HR, payroll and so on.

They are not market. Differentiating activities in these quadrant are important, but they do not provide an advantage, so adoption of existing best practices is the typical strategy here. You don’t need to invest in innovation in this quadrant. Activities in the partner quadrant may have unique value to customers, but are not critical to the functioning of the organization. Even though these activities are important to your stakeholders, your organization doesn’t need to perform them to survive.

This means the organization is unlikely to have the resources to excel at these activities, while a partner may perform them more efficiently. So these are likely to get outsourced or acquired on the market. Finally the who cares bucket. The title says it all. These activities do not add customer value and the organization can function without performing them.

So they are the prime candidates to be eliminated, so the resources can be reallocated to support more useful work. Unlike previous technique, Cannot Analysis looks at the features from the end users point of view. It helps to identify which features are viewed by the customers as absolute must, or something they would be surprised and delighted to see in the product.

The trees hold characteristics of the product are absolutely necessary for stakeholders to consider the solution. Their absence will cause intense dissatisfaction, but as they represent minimum acceptance criteria, their presence will not dramatically increase customer satisfaction. The challenge with developing requirements for these features is that people expect them to be present and tend not to think about them unless explicitly asked.

The performance characteristics are those for which increases in the delivery of the characteristic produces a fairly linear increase in satisfaction. They represent the features that customers expect to see in a solution such as speed, ease of use and so on. Requirements for these types of features are likely to most readily come to mind for the majority of stakeholders and the final group, the excitement attributes.

These are those that significantly exceed customer expectation or represent things the customer did not recognize were possible. Their presence will dramatically increase customer satisfaction all the time and this is your innovation in the product or critical competitive advantage. There is another bucket of characteristics in different characteristics. These are the ones which add no value to the customer and the customer does not want them. These characteristics are not represented on the graph because they will negatively affect customer satisfaction and should be described completely. Regardless of which prioritization Framework You Want to Use either you want to use one of these two or you want to develop your own.

Depending on your business situation and organization you work for, it is important to remember that this framework is an aid during the prioritization process. The process itself may go very much like the process that we discussed when we were talking about Product Roadmaps and MVP. Basically, you look at your list of features or list of user stories, and for each individually, you assess it against your prioritization framework to understand how important this feature is for you and for your project. And then you make the calls whether this feature goes upper in order of priorities and in earlier releases, or it goes down, or maybe goes to Dscope at all.

6. Agile estimation

Typically story estimation in Agile is relative. It means that you do not estimate stories in amount of hours it would take to complete them, but rather you give them a relative indication of complexity, often called a story point. Collecting statistics on how quickly the team delivers certain complexity, you can calculate teams velocity. That means you will know how many story points a team can deliver within a given time frame, say within a sprint. And then this velocity will be used to project the delivery timelines. Now let’s have a look at how the stories can be estimated. Playing poker is a playful and very popular approach to estimation that is used by many Agile teams. It works like this. First, each team member will have a set of playing cards. On each card there will be a number, typically one to 16, or even more than that, depending on the scale that the team uses to estimate the stories. Each card represents a user story estimation in points.

 Then, for each of the user stories, each member of the development team will silently pick an estimate and prepare the card. But the person will not show these cards to other team members. Then, when everyone is ready, everybody turns their cards face up at the same time and the estimates are compared. The two or more team members who gave the highest and the lowest estimates will justify their reasoning. They will talk about how they estimated, what they taken into account, and why they gave this estimate to particular story.

And then another round is played till the team reaches consensus. For the planning poker to run successfully, the team needs to have a baseline. Baseline means they have the example user stories for each story point estimation. And they compare the new stories that they estimate to the baseline stories, so that they can easily pick a card.

Let’s have a look at how we establish a baseline. Well, at the start of the project, you would have a list of stories that are not estimated. So you ask the team to take this list and group them together from the easiest to the hardest, asking them to put the stories that are relatively same complexity next to each other. If another story appears to be two times harder or two times easier than the ones already selected, to place them up or down from the selected stories. So eventually you end up having something like this stories arranged by complexity. If the complexity is the same, they see it to each other. If complexity is noticeably higher or noticeably lower, they sit up or down on the scale. And then for each group of user stories, you assign story points, in this case, one to eight. It is very popular that the teams use Fibonacci sequence for story points. So it goes like 1235, 813 and so on and so forth. This indicates that the complexity grows higher the higher story points. You give. So between the stories six and five, it means that story five is noticeably or two times more difficult than story six. And now, when this baseline is established, the team can start working on these stories to figure out how many of these story points they can actually deliver within a sprint to establish the velocity that will be used for planning. Now, let’s see how we can apply this knowledge to an estimation of a single story. So let’s take this story as an example.

 It comes from one of our previous exercises. As a customer who receives SMS bills, I want to see the due date and payment amount in the SMS so that I know when and how much to pay. You take your team, these four people, and ask them to look at the story. As a business analyst. You present this story to them during the session. You explain what it means and you explain the acceptance criteria for this story so the team knows what is involved in delivering it. Then you ask them to estimate it. They pick up their cards and when they’re ready, they show the cards. As you can see, the estimates are quite diverse, going from the lowest one to the highest eight.

So you ask the people with the highest and the lowest estimate to provide their reasoning why they think this story is easy or hard. After that, you ask the team to reestimate, taking into account the new information that was discovered during the conversation and after the reestimation, when everybody is ready, they show their cards again and eventually they will reach consensus. This is how you apply planning poker to estimating the stories. This story will eventually receive the estimate of five, meaning it has similar complexity as other stories in your backlog with an estimate of five and now, based on your team’s velocity, you can project how long it is likely to take care team to deliver this stuff.

7. Mapping the principles on initiative horizon

Now let’s see how the principles of Agile analysis are applied to the initiative horizon. The first one see the whole you need to tailor your decisions about solution components to this strategy. Make sure that whatever you do in your initiative is aligned to the overall strategy. The sequence of delivery should be based on needs that you have identified and the needs need to be reassessed every time you deliver a new solution component. The principle of think as a customer is applied when you consider the needs from the customer’s point of view. When you prioritize the backlog, you support the creation of available solution with minimum output possible, and you consider the feedback that you receive from your customers. From early delivery, you deliver something, you learn the feedback.

You apply the feedback to the next iteration and that’s how you make your product better. Analyze to determine what is valuable. You use this shared understanding of needs to determine solution options. You also call out solution components that do not deliver value so you can save resources and not waste them. Get real using Examples You start with examples that represent the most common scenarios your customers are likely to face. You also can use examples in your backlog as acceptance criteria to your backlog items. Understand what is Doable do not attempt to deliver new solutions when you can deliver value. Reusing existing ones. Try to reuse as much as possible to minimize the effort wasted. Use feedback from your team as well as the feedback from your customers to help shape the backlog and try to reduce the effort spent on not feasible solutions.

Stimulate collaboration and continuous improvement. Make sure that decisions are based on information provided by Crossfunctional team that you’ve got input from all of the functions involved in the delivery. And also make sure that your decision makers are available for the team when they are needed. Avoid waste. Apply the results of what is Doable to avoid rework and make informed decisions. Also ensure that there is a shared understanding of the scope for the team and stakeholders. If you apply these principles to your initiative level analysis, you will succeed on any initiative. Trust me.