Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Q&A on Analysis Techniques for Product Owners Live Lessons

Q&A on Analysis Techniques for Product Owners Live Lessons

Key takeaways

  • Kent McDonald gives Product Owners a handful of analysis techniques for Product Owners to build and maintain a shared understanding and put outcome before the output.
  • Reasons why you need to first specify your problem before digging into the solution.
  • Focus on the outcome instead of the output that is, focus on satisfying a need instead of delivering a solution.
  • Distinguish between personas and user roles and how do they map into the problem and solution spaces.
  • How asking the right questions can leverage the analysis techniques described.

In the Analysis Techniques for Product Owners video lessons, Kent J McDonald shared a set of techniques that will help you build and maintain a shared understanding and put outcome of a project before the output.

The author of Beyond Requirements: Analysis with an Agile Mindset shows various methods to better:

  • Understand the stakeholders of a project.
  • Comprehend the organizational context.
  • Assess the need to be satisfied.
  • Build and properly communicate the solution to be delivered.
  • Organize and persist solution information.

InfoQ spoke to McDonald to get further insights on those topics and to dig into some of the techniques presented.

InfoQ: Product Owners are best known as players in the agile field. Why did you feel the need to compile a quite extensive set of analysis techniques for them?

McDonald: The question seems to hint at an assumption I see periodically - that analysis is not relevant when working in an agile fashion. I believe that is an incorrect assumption.

Analysis, when practiced at the appropriate time, to the appropriate extent, using the appropriate techniques for the situation is very helpful regardless of what approach you use. Analysis techniques are especially helpful for understanding a complicated domain (see Chris Matt’s post on using Cynefin to understand where business analysis applies) and pulling together information to help make decisions such as:

  • is the need worth satisfying?
  • what is the best solution for satisfying that need?

Those are decisions that product owners should make. Depending on their background, people playing the product owner role may or may not have experience with analysis techniques, so I wanted to compile this set of techniques to provide them with tools they could quickly pick up to use in their role.

Another intended audience is business analysts who have knowledge about analysis techniques, but may be new to working in an agile fashion and need some advice about using the appropriate techniques, at the appropriate time to the appropriate extent. These business analysts may be filling product owner roles where they are making the above decisions, or they are helping product owners to get the information necessary to make the above decisions.

InfoQ: You start your lessons by mentioning the Core Concepts from the IIBA. Can you detail it and explain how it helps on delivering the most valuable solution?

McDonald: I included a discussion of the BACCM, and the other ideas (outcome and output and discovery and delivery) in the first lesson because I found them to be helpful concepts that underlie why I included the techniques I did in the rest of the lessons.

The BACCM provides a good level setting of terminology used in the analysis space and thus helps to establish a ubiquitous language for teams working together to satisfy a particular need.

InfoQ: Implementing and delivering the solution should come after identification of the need. What if one tries to describe the solution before assessing the problem. What risks are brought to the table by doing that?

McDonald: There are a few risks when you have a solution in search of a problem.

1) The solution does not address any of an organization’s needs. This can happen when someone with influence stumbles upon a shiny new software tool, business process, or methodology and insists that the organization implement it without really knowing why. At the very least the organization wastes time and money, and may even have a negative impact on the organization’s results. This can also lead to morale problems for the team implementing the solution when they realize that the aren’t adding any value to the organization.

2) The organization doesn’t address their real needs because people and money are focused on implementing non value add solutions.

3) A solution is relevant to an organization’s need but the team implementing the solution doesn’t understand what that need is or what it means to satisfy it. In this case the team may over-engineer the solution, or deliver the solution later than when it could be most effective. This again leads to wasted time and money.

If an IT organization repeatedly experiences these risks, they lose credibility with the other parts of the organization. Those business units will start looking other places for their IT work. This lead to a great deal of “shadow IT” and an even bigger burden in terms of support and integration down the road.

In order for IT to have an effective relationship with the other parts of the organization they have to make sure that a definitive effort is made to understand what needs exist for the organization and which of those needs should be satisfied first. IT is not necessary the one making those decisions, but they should certainly make sure that the appropriate discussions are happening, because they are in control of when and how solutions are implemented, so they sit at a good decision point.

Analysis Techniques for Product Owners describes how you can use goals and objectives to describe the needs you are trying to satisfy and what satisfying those needs looks like. This gives some guardrails for delivery teams to apply their understanding of the available technology to determine appropriate solutions.

InfoQ: You highlight an idea of focusing on the outcome instead of the output. Can you explain the difference?

McDonald: Outcome is the change in the organization and changes in the behavior of stakeholders as a result of your team’s work. You can also think of the outcome as satisfying the need.

Output is anything your team delivers as part of a project. For example: software, documentation, or process. You can think of output as the solution you deliver.

Any effort I work on, I want to figure out how I can maximize the outcome with minimum output. This means if I can satisfy a need with a simple process change, that is better than developing a bunch of software to accomplish the same thing - because I haven’t added more software to maintain and keep updated.

Unfortunately, most projects measure progress and success based on output (completed stories, velocity, “earned value” management) rather than outcome (objectives met). This reinforces the risk I mentioned earlier that some solutions get over-engineered or more solution is delivered than necessary because that was what was included in the original scope. Scope that, I should mention, was identified when the people working on the project were at their point of maximum ignorance about the project.

InfoQ: The continuous improvement cycle you describe, from discovery to delivery, incorporates an idea of not splitting design between them. Can you explain how it works?

McDonald: I basically included the discussion of design based on a reviewer’s question from an early draft of Beyond Requirements: Analysis with an Agile Mindset. That reviewer asked why I didn’t have three steps, discovery, design, and delivery. I considered it for a bit and realized that separating design out really didn’t provide any value because design, like analysis, occurs throughout the effort during both discovery and delivery.

Design occurs in discovery through the use of design thinking techniques to gain a better understanding of users, and through describing the solution using models, examples, and acceptance criteria.

Design occurs during delivery as your team figures out how to technically satisfy the user stories given your chosen technology and architectural constraints. That activity is interwoven with development and testing as your team will have some initial discussions about design but then revise that understanding as they learn through experience.

Calling design out as a separate activity doesn’t add any value to the process and leads to pointless arguments about whether a particular item is in discovery, design, or delivery, whereas having an explicit split between discovery (understanding what to deliver) and delivery (delivering it) is a much clearer delineation.

I like to keep the processes and techniques I use fairly simple. Simple practices are more likely to be used, and you can avoid the pointless arguments mentioned above and instead focus on what should your team do in this situation to better understand where to go next and what decisions to make.

InfoQ: Regarding Stakeholder Analysis, you talk about a technique called Commitment scale. Can you show what it adds to a more typical impact / interest analysis?

McDonald: One of the lessons describes the Stakeholder Map, which is a tool you can use for a typical impact/interest analysis. This analysis (most effectively done as a conversation amongst the team) helps you to determine how much interest various stakeholders have in your project and how much influence they have. Where they land provides guidance on how you should interact with those stakeholders.

The commitment scale adds to that analysis by acknowledging that politics exist in your organization and providing a means of discussing your stakeholder’s assumed attitudes toward the project. Your team discusses various stakeholders and where they currently fit on a scale from Enthusiastic Support to Hostile with several conditions in between. You then discuss where you think you need the stakeholders to be at in order for the project to be successful. You don’t need everyone to be an enthusiastic supporter, but if you have a stakeholder who is outwardly hostile and has a great deal of influence, you may need to do some things to move that stakeholder up the commitment scale.

A big caveat with the commitment scale is that it’s not something that should be published and may be better served as a discussion topic than a specific artifact. It’s key purpose is to help your team determine how best to interact with your stakeholders and whether there are some that you may need to take some extra effort throughout the course of the project.

InfoQ: User Stories target a user / profile / persona that benefits the most from an implementation. Can you explain what is the difference between a User Role and a Persona? Can you some examples

McDonald: I think there is some confusion out there about personas and user roles, and I suspect I’ve suffered from that and added to that confusion at some point. The difference comes down to whether you are trying to identify needs or describe solutions.

Personas are particularly well suited for identifying needs. You want to identify and describe the key people whose needs you are trying to satisfy. It’s focus is on discovery. You will not cover all the people here who may be have a specific need, just the key ones.

Users Roles are more appropriate for describing the solution. The purpose is to describe the different types of users who use the solution, provide context around the users and to aid solution development. This description may also be used for a very analytical activity of identifying what actions particular users can take with the solution.

It just so happens that some of the techniques that are useful for describing personas can be useful for describing user roles because you look at some of the environmental factors that people face when using an application.

As an example, take Reed the Reviewer that I used as an example in the Live Lessons. I used a template that Jeff Patton suggested for describing a persona to describe Reed. The information collected provides some good information about the way Reed works and the environment in which he works which provides some insight useful for developing the submission system. Reed probably would not be a key Persona for the Submission System, because his interaction with the Submission System is to enable the actions that satisfy others needs. The key personas for the Submission System are probably Sam the Submitter and Connie the Conference Chair.

If I were just tackling the Submission System from scratch, I’d probably create Personas for Sam the Submitter and perhaps Connie the Conference chair, so that I understood their key needs. One persona representing people submitting ideas, and another person representing the people selecting the program. We’d then probably identify several other User Roles to flesh out the solution, but wouldn’t use them to identify problems so much as to describe aspects of the solution.

InfoQ: Decision Filters is a technique used for proper identification of a need. Do you have some tricks to share on how to build effective decision filters?

McDonald: Identify a few questions that encapsulate what you are trying to accomplish with your organization, product, project, release, or iteration. Use those decision filters to guide choices about what to do and how to approach it.

Depending on the type of decision you’re trying to guide, decision filters may be restatements of other key ideas such as objectives, conditions of satisfaction, or key success criteria. Regardless, decision filters are usually created the same way—through conversations.

Decision filter conversations usually include all of the people who provide the filters (the objectives, conditions of satisfaction, or key success criteria) and some of the people who have to enact the decisions. For more tactical decisions, the conversations will include more people who have to enact the decisions. These conversations can provide a great deal of background information for teams, but eventually people who weren’t involved in these discussions will need to use the resulting decision filters. It is for those folks that the decision filters are really being created, to help guide their decisions on a day-to-day basis.

InfoQ: During the lessons, there are a few references to techniques using questions. In your opinion, why is this method so powerful?

McDonald: I like using questions because they tend to encourage discussion, and get thoughts about risks, assumptions, and constraints out of people’s heads and shares them with the team. Getting that information out in the open helps the team build on each others ideas. Questions are also very helpful when they structure the conversation - keeping it focused on very specific topics. I also find that the right questions, asked in the right manner help to spark those difficult, but necessary discussions that when had early can prevent efforts that waste a lot of time and money. They question best suited for those types of discussions: “Is it worth it?”

InfoQ: Project Opportunity Assessment is used above all to keep an organization from wasting time and money. Well, this is kind of a definition of being agile and led to the elimination of big upfront design. What is the effort needed for an assessment like that?

McDonald: One of the 12 Principles Behind the Agile Manifesto is “Simplicity--the art of maximizing the amount of work not done--is essential.” That principal led to the elimination of big upfront design because many aspects of “Big Upfront [fill in the blank]” don’t add value, primarily because the assumptions change from “we can know everything up front” to “we can’t possibly know everything upfront, so we need to know enough to move forward and make sure we’re doing things along the way to learn more.”

The Project Opportunity Assessment isn’t related to big upfront design. It’s a way of taking a look at an idea and ultimately determining “Is it worth it”. This discussion does not have to take a great deal of effort as long as the team realizes they may need to answer that set of questions multiple times. The first time you answer those questions, you’re trying to decide if it’s worth to even start working on the project. To put some forth some effort that will help you build some things which will provide more information to answer some of the questions in a little bit more detail.

I’ve worked with a couple of teams that discussed the Project Opportunity Assessment during a day long planning session. The questions basically provided a way of guiding the conversation and helped the team address the necessary information to make a decision about whether to proceed or not. Other times, the sponsor or product manager has prepared her answers to the questions ahead of time and then discussed them with the team, both as a way of building a shared understanding about the project and to help come to a conclusion. In one case a product manager hadn’t answered the questions, because she didn’t feel she had enough information. The team took this lack of information as a clear sign that the project was not worth undertaking at the moment.

Unfortunately not enough organizations undergoing “agile transformations” honestly ask the question “is it worth it” about all the projects/products they work on. Rather they concentrate on adopting practices associated with the more popular “frameworks” and forget that one way to be agile is to not work on things you shouldn’t work on. If you don’t do big upfront design on a project you shouldn’t be doing in the first place, are you really being effective?

InfoQ: You describe Story Mapping in the solution lesson. Isn’t it part of the problem space too?

McDonald: No.

You need to have a clear idea of what need you are trying to satisfy in order to focus on the particular process, product or feature you are going to use story mapping to understand. If you were to use a Story Map to try and understand the problem, you are falling victim to diving into a solution in order to describe the problem, which can very quickly lead to the risks discussed above. Start with a clear understanding of the need and how you know you’ve satisfied it (preferably through measurable objectives) then use the Story Map to explore different solution options.

Story maps as originally described by Jeff Patton are a very helpful elicitation technique when trying to understand a solution that has a great deal of user interaction. Creating the story map guides the team as they talk through the business process, identify the key activities (represented as features), and lay them out in a logical sequence.

There are many cases where the solution does not inherently support a single process or a logical step-by-step order is not so clear. In those cases, story maps can still be useful for visualizing the relationships between features and user stories and representing when specific user stories will be delivered for a given feature.

InfoQ: Do you feel front end design as being part of the analysis?

McDonald: I don’t get too hung up on whether something is design or analysis because I don’t find quibbling over arbitrary classifications to be particularly useful. (Another form of simplicity).

I do know that sketching user interface prototypes while talking with stakeholders and users is a great way to talk about what information they want the system to collect, remember, and present. For example, by discussing which UI control (radio buttons vs. check boxes vs. drop down lists, etc.) I should sketch for a given form, I can identify business rules that are relevant for the solution.

User interfaces are a helpful elicitation tool because most stakeholders are familiar with them and can relate to them. By sketching those UI as part of a discussion, you can use an additional communication channel and stand a better chance of building shared understanding.

InfoQ: Maintaining useful and updated project information is quite hard. Do you have any techniques to share with the audience that might help on that?

McDonald: I like to use the concept of system documentation to maintain information about a project on an ongoing basis. System documentation is information about an as-built solution and acts as a reference for future maintenance or update efforts. It is organized based on system functionality rather than when changes were made to the system, making it easier for people who maintain the solution to find the information they need quickly.

While the solution itself (and tests written against it) can provide a great deal of information, there will always be a need for additional sources of information, especially for aspects that are not readily apparent. This information can take many forms, but I usually like to have some combination of the following:

  • Glossary: definitions for the commonly used terms in the domain in which the system operates
  • Business rule catalog: descriptions of the rules, though without indicating how those rules are enforced (that information is typically noted in one of the other artifacts or represented by tests)
  • Metadata: data about the data that the system collects, stores, and provides
  • Process flows: descriptions of the business processes that the system supports
  • User interfaces: descriptions of the operations behind the scenes or the enforcement of business rules related to the user interface
  • Permissions: a description of which roles can perform which functions in the system

System documentation is helpful anytime you have a solution that will be maintained and updated through its lifetime. In a broad sense, this applies to most systems built or implemented by an IT organization. System documentation is especially helpful when the system is maintained or updated by a different team from the one that originally built it and can even be useful for solutions that are built and maintained by the same team, especially if the solution is expected to have a long life (say, more than a year).

When you do system documentation, you are creating documentation with a purpose, and once you know that purpose it’s usually a good idea to structure the documentation based on its purpose. In the case of system documentation, you want it to reflect the current state of the solution as built, and you want it organized in an intuitive way—most likely based on how the solution itself is organized.

About the Interviewee

Kent McDonald helps organizations understand and solve the problems that they face. He is active in the business analysis and Agile software development communities helping people share stories about what does and does not work. Kent is the product owner for the Agile Alliance conference submission system. He has written a new book "Beyond Requirements: Analysis with an agile mindset"

Rate this Article