Product Owner vs. Business Analyst

So, what is the difference between a Product Owner and a traditional Business Analyst? Well, that is a complicated question to answer. But let’s dig in. First, in Scrum, the Business Analyst role does not officially exist. If you recall, you only have three roles: Scrum Master, Product Owner, and the Scrum Team. That’s it. The Product Owner is the appointed representative of the Business; they are the voice which drives the Scrum delivery processes. A Product Owner:

  1. Represents the “Voice of the Customer”

  2. Develops and refines the Product Backlog

  3. Defines business value of Product Backlog items

  4. Establishes the priority and optimizes value of the work the Scrum Team performs

  5. May or may not write the User Stories

At a high level, a Product Owner is generally less technical and is more oriented towards the business. In a lot of respects, from a traditional Waterfall view, they function both as the SME and perform less technical BA work. As we stated earlier, a Business Analyst does not exist on a Scrum Team, so where do they go? This is where things get organization specific.

Some organizations will absorb the BA and they will simply become part of the Scrum Team. On a Scrum Team, a Business Analyst might:

  1. Write the User Stories

  2. Perform additional analysis which will become artifacts during the Sprint (process models and diagrams, data dictionaries, low and hi-fi prototypes)

  3. Execute UAT (write test cases, execute tests, maintain issues log)

In other organizations, a Business Analyst will transition into the role of the Product Owner. Meaning they will typically become more involved in the business side of the organization and less embedded within IT. The success of this transition will largely depend on the person’s ability to adapt and being comfortable representing the business. A Business Analyst is traditional a liaison between the Business and IT; a Product Owner represents the Business and product itself.

As Is, To Be, and Gap Analysis

One of the most important tools in the toolkit for a BA are modeling the “As Is” and “To Be” business processes and finally performing the “GAP” Analysis. At the highest level, we are trying to identify and document what is currently occurring, what we would like to see happen in the future, and ultimately find the gaps between these two states. This type of analysis is usually focused on business processes; this can and typically does overlap with system functions (technology).

The "As Is" analysis focuses on the current state of the business in terms of its processes, including any pain points which need to be resolved. The goal is to bring clarity to what is occurring in an organization. Information is elicited from Stakeholders and SMEs who are either:

-       Performing these business functions, or are

-       Responsible for managing these processes and/or

-       Responsible for the outcomes of these processes

This information is typically boiled down into a Business Process Model. These models are a simplified, graphical representation of the real-world business processes which are occurring for an organization.

The level of decomposition of these models will depend upon the stated goals of the project. For example, if you are attempting to gain organizational efficiencies and are reengineering business processes, it is likely your models will be decomposed into a great level of detail. For most projects related to application development, this level of detail is usually not required.

The "To Be" analysis is focused on creating an ideal state of business processes in the future. The goal here is to begin identifying opportunities for improvement. Many times, processes can be automated through the creation of new applications, or enhancements to existing ones. Whereas some business processes can simply be tweaked to gain efficiency, while others can be added or removed. Time savings, opportunities to cut costs, or improve quality can all be realized through this type of analysis.

Alright, so now you have a high-level understanding of the “As Is” and “To Be analysis”, so what is “GAP” analysis? GAP analysis is simply the process of identifying the holes between your “As Is” and “To Be” analysis. A great way to think about it is identifying what steps need to be taken to fulfill the “To Be” process models. Here we are, and here’s what needs to occur. For all intents and purposes, most of your work during the project will be here, filling the gaps and implementing the “To Be” models.

As a Business Analyst, this type of analysis isn’t always required. However, it can be extremely useful on most projects. During my experience, there have been many occasions in which being detail-oriented during this phase paid off with uncovering hidden requirements. Furthermore, this is where you typically find your opportunities for improvement, or even unseen pain points. I will leave it here for now, but I will definitely be expanding upon this topic in the future; the primary focus will be on what I look for when conducting this type of analysis. 

The Value of Application Prototyping

Why do so many application development projects fail? In many cases, the reason for this are inaccurate or incomplete requirements. The move towards "Agile" was a way of combatting this. Those evangelizing this gospel will contend that changing requirements are a part of life and should be embraced with open arms. These enthusiasts propose you can flex product scope, while still meeting the business need and fitting within the time and resource constraints of a given project. Much of this is true. However, we can still do better!

But how? Ask yourself this. Would you ever buy a new home without seeing a model home? Would you ever buy a new car, without test driving it? Or buy a new shirt without trying it on? The answer to that is clearly “No”. We understand the reason intuitively, people want to test things and try them out before they make a buying decision. In the example of buying a new home, we know that most people would never buy one solely based upon Architectural drawings and sketches. It doesn’t matter how detailed these drawings are, it’s never going to happen. Then why on earth would you deliver an application without giving the Users the ability to test drive it, before it’s been developed?

Yes, stakeholders should know exactly what they are getting before it's produced. Or at the very least, something close to it. This is where prototyping comes into play. The key here is that we're translating their wants and needs into something that's both visual and tangible. We all know that most people are visual learners; your stakeholders are no different. Most stakeholders will have trouble digesting a 300-page specifications document; similarly, most will also have trouble conceptualizing a set of User Stories in an Epic. However, most if not all, can easily understand a working prototype. It’s so much easier for them to give feedback, and ultimately approve the work. In addition, prototyping can give the team a head start in terms of UX/UI, which is a huge bonus.

To be successful as a Business Analyst in today’s competitive environment, adding a skill like prototyping to your toolbelt is a huge advantage. It’s worth your time and effort to learn. So, let’s look at some more of the benefits of application prototyping:

1.    Cost Savings

The biggest benefit of prototyping is obvious, it’s the ability to save on costs. Coding is very expensive and time consuming; while you can make very large-scale changes to a prototype on the fly.  

2.    Minimize Re-work

Even if we’re working in an Agile-based environment, we still want to minimize rework. There is a significant difference between making changes based upon a business need, as opposed to a misunderstanding. One is highly productive, responding to marketplace signals. The other is unnecessary and is very costly. Prototyping can largely solve this.

3.    Increase Delivery Speed

A big morale boost derived from prototyping is the ability for the team to deliver more, in a shorter amount of time. Prototyping removes a lot of the ambiguity and guesswork out of the application development process; this time can be better spent on delivering the end solution.

Hopefully I have been able to convince you to start prototyping your solutions starting today. If not, it would be wise to at least think about adding this technique to your requirements gathering process. A less involved technique would be to start wireframing some of your end solutions; this can be very effective and is extremely simple for even a beginner. Any way you slice it, the more visuals you can add to your Requirements or User Stories, the better off you will be.

Acceptance Criteria, User Stories, and UX

Many Agile purists will argue User Stories are NOT requirements; their contention is that User Stories are goal oriented, while Requirements decompose product scope. This is partly true. Functional Requirements tend to be descriptive of a solution; however, the actual Business Requirements should be goal oriented. Hence, a statement of business need. Having worked with many Application Developers during my career, I can understand their frustration. Most developers want to avoid being “boxed in” to a solution and want the flexibility to build solid applications. In many cases, a Business Analyst will step over the line and will begin recommending solutions which either won’t work, will be too complex to develop, or will take too much time to develop. User Stories are a way to keep non-technical folks from stepping over those boundaries. Whether you’re writing traditional BRD’s, or User Stories, understand these are two METHODS which seek to achieve the same results.

We are in the business of transforming human thought, into tangible “Products” (usually applications) that achieve a business goal or solve a business problem.

The utilization of Acceptance Criteria to ensure software (a product) meets stakeholder needs is very common. In the "Agile" realm (for all intents and purpose, SCRUM), Acceptance Criteria define the boundary of the User Story; basically, it's how we can tell if the story has been fulfilled and is working as intended. In terms of language, these criteria are lower level goals the User wishes to achieve, decomposed from the higher-level User Story. For BA's, it's very similar to the way higher level Business Requirements are decomposed into Functional and Non-Functional Requirements. In that model, we are clearly stating business needs and describing the solution(s) in more and more detail.

In Agile, these Acceptance Criteria are then transformed into Test Cases; this ensures we have a Pass/Fail verdict for each criterion (and ensures that we have traceability). The idea of using a Pass/Fail method for testing quality infers Acceptance Criteria are objective. For the most part, this is true.

However, there is a major exception to this rule. User Experience. With UX, we are talking about the User’s subjective experience interacting with the web site or application. This is not to be confused with Usability, which has a narrower focus ensuring a “product” enables the User to complete a set of tasks. This means we are dealing with the User’s attitudes and opinions of the product we are delivering, not just whether it works as specified.

As many of us who have worked in custom application development for any length of time understands that this poses a challenge with regards to measuring success. We can use a variety of techniques to gain insight into a User groups’ satisfaction with our product. We can even have a fairly good idea as to their likes and dislikes. However, we must understand this is not a hard science, but can have a tremendous influence on our success.

A great example from about 10 years ago was the launch of the iPhone. Apple introduced a product which would completely revolutionize how the world communicates. This wasn't by done by accident. What set Apple apart wasn't just the functionality, it was the User Experience. From the slick packaging and presentation of a brand-new iPhone, to the building of anticipation of every release – Apple created a brand-new segment of the cell phone market which it would dominate for years to come – the smart phone.  

Over the years, many competitors have attempted to replicate this success. The devices have become increasingly sophisticated, with an astonishing amount of functionality packed into a small unit. While the competition could match the physical qualities of the iPhone, most were unable to match Apple’s success. Do you remember the Blackberry Storm? I don’t either.

So, what does this all mean? The most important implication of this example is that it is NOT enough to focus on objective measures of success. Fulfilling a User Story and passing Acceptance Criteria is simply a starting point, the attitudes and interest of your Users may be even more important. It’s not just what your Users can and want to do, it’s how they feel about what they’re doing. Their attitudes and opinions can ultimately make or break your project, so it’s very wise to pay attention.  

Anatomy of a User Story

So, what is a User Story? In the field of software application development, a User Story is a brief description of a feature of an application told from the perspective of an End User (typically). The language is plain, and avoids the extremely formal verbiage used in a typical Requirements document (e.g. “The system shall do X, Y, & Z”). The format and structure of a User Story is also fairly simple:

As a [End User]

I want to be able to [Insert a description of the application functionality]

So that [Insert a description of the business value realized]

Acceptance Criteria:

  1. List acceptance criteria #1

  2. List acceptance criteria #2

  3. List acceptance criteria #3

As you can see, the overall structure of a User Story is relatively simple. However, things can get very complex quickly based upon the type of functionality you are attempting to describe. The most important thing isn’t actually the User Story…it’s the Acceptance Criteria associated with the User Story that is most critical. If we do not define the Acceptance Criteria, we can never know whether if the User Story is complete.

Think of it as a funnel, at the top is your User Story…it’s your high level goal. As we move through the funnel, we are testing against each piece of Acceptance Criteria. Only when each Acceptance Criteria has been fully tested and passed, can we consider that User Story to be complete. If you’re a Product Owner, or a Business Analyst working under a PO, you probably already know that writing the detailed AC is where you will be spending most of your time.

In terms of Requirements gathering, are User Stories enough for large scale application builds? No. User Stories and Acceptance Criteria are typically a starting point when it comes to analysis. Developing the AS IS and TO BE process models, writing the Business/Data Dictionaries, and defining the Use Cases are just an example of things that still need to be done on the majority of projects. These artifacts are critical for a DEV team member to be able to do their job…swapping out a BRD for User Stories does not change that fact. So having that BA skillset is still required, now more than ever.  


What is Agile governance?

In order to answer this question, we need to clarify terminology up front. Agile is typically short hand vernacular for SCRUM. When most people think of “Agile”, they really mean “SCRUM”. In reality, Agile is more a philosophy and mindset towards business:

·         Kanban is Agile

·         SCRUM is Agile

·         XP is Agile

When it comes to software development, Agile is an effort to maximize business value, while minimizing waste.

Examples of these include:

Kanban is a lean manufacturing approach and scheduling system originally developed by Toyota; its focus is JIT manufacturing. This concept has made its way over into the IT world.

XP refers to Extreme Programming. Extreme Programming (XP) is an iterative approach to programming and focuses on frequent releases. These iterations may go a week or two at most (SCRUM sprints are typically 2-4 weeks). XP also provides some prescriptions on development practices (such as pair programming or automated testing).

SCRUM is a lightweight, product delivery framework for application development (SCRUM is not Project Management). In terms of requirements, SCRUM only has four ceremonies:

·         Sprint Planning

·         Sprint Review

·         Sprint Retrospective

·         Daily Stand Ups

And three roles:

·         Scrum Master

·         Product Owner

·         The Team

So when we look at these Agile delivery frameworks and practices, we must understand they do not exist in a vacuum. We still need ways to manage the supporting projects, and ensuring the product delivery meets its targets. We need some governance.

Now, when I say governance, I do not mean a rigid process that ties people’s hands. But we can’t have the Wild West either. Each organization will need to develop a reasonably structured approach to managing these App Dev projects, while enabling their software delivery teams to achieve success.

It’s reasonable for the project team to develop a Project Charter, to estimate costs in terms of time and resources, or to identify/manage project risks. Getting the status on software delivery on a weekly basis is also not unreasonable. That’s effective Agile governance. What we don’t want to do is burden these teams with unnecessary tasks and busy work.

Effective Agile governance is really being able to identify what things add business value, what is required, and what tasks/artifacts that are not necessary. It’s trimming the fat, and being lean in terms of the environment, structure, and processes surrounding your App Dev projects.