Stop Managing Software Projects

Manage Software Products Instead

Table of Contents

If you are managing software development efforts as projects, you are doing it wrong. Instead of managing projects, organizations that sponsor and develop software solutions need to shift towards managing solutions as products. A product management approach to software development aligns with modern software development and with Agile’s inherent product management bias.

Project Management vs. Product Management

In a nutshell, project management differs from product management in that the former is primarily concerned with managing people, schedules, and tasks while the latter focuses on managing the product and how it is created.

Traditional project management is misaligned with modern software development for two reasons:

An overemphasis on managing the triple constraints of the “Iron triangle” to the detriment of technical execution, product quality, and value delivery
An overemphasis on control to the detriment of speed and flexibility

The “Iron Triangle”

Traditional program management focuses on enforcing the triple constraints of the Iron Triangle: cost, schedule, and scope (the amount of work done). The objective is to deliver expected value on time and on budget. Unfortunately, fixing the three constraints leaves quality as the only variable, opening the door to sacrificing quality when things don’t go as planned. Because no one can predict the future, most traditional projects fail to deliver on at least one of these constraints. In other words, “I can get it to you cheap, fast, or good. Pick any two.”

Traditional project managers manage against detailed plans that attempt to fix all three constraints for the life of the project. They base plans on estimates of how long it will take a certain number of people, with specific skills, to accomplish a set amount of work at a certain cost. As problems arise, managers work to keep the project as close to the original plan as possible. If project reality strays too far from the plan, they develop a new project plan or scrap the project altogether. Replanning is a risky and expensive proposition, so project managers work mightily to avoid it.

Fixing cost and schedule begins by fixing scope. The more detailed project requirements are upfront, the more precise the cost and schedule estimates become. However, these calculations are not necessarily more accurate because they are based on estimates and on requirements that will likely change the bigger and more complex project scope becomes.

How Enforcing the Iron Triangle Affects Software Development

The problem with applying traditional project management to software development is that development of non-trivial and/or large-scale software solutions is too complex for linear predictive planning. As software solutions grow and evolve, their complexity increases, sometimes at a seemingly exponential rate. Since we can develop and modify software solutions in infinite ways, they are often significantly more complex than physical systems of comparable cost.

Enforcement of the Iron Triangle in software development projects often leads to the following problems:

Narrowing requirements and technical approaches too early – Predictive project planning typically forces teams to define what they will build and how before they really understand the business/mission and technology domains they will work in. This often leads to developing things that customers and end users do not need or that do not adequately address their needs.
Tendency to overengineer solutions – Specifying technical scope upfront often leads to overengineering. Defining and developing features that few, if any, customers or end users will actually use is quite common. Also, overengineering can lead to creating complex features or functionality where simpler versions could have satisfied requirements. All those rarely-used or overly complex features cost money to develop and maintain. They rob time and budget from developing and releasing features customers and end users truly value.
Difficulty managing risks and taking advantage of opportunities – In the zeal to keep projects “on plan”, planners often identify emerging risks too late to keep them from becoming issues or forgo opportunities to improve the product and how it is developed.
Forgoing opportunities to validate solutions – Projects based on predictive planning, such as Waterfall projects, often afford only one chance to validate what teams develop. Typically, validation of the solution occurs towards the end of the project, when the time to address problems is most limited.
Delaying delivery of business or mission value – With only one chance to deliver / release, sponsors, stakeholders, customers, and end users must wait until the end of the project to gain access to solution features.

Agile “Breaks” the Iron Triangle

Instead of attempting to fix all three constraints of the Iron Triangle, Agile fixes cost and schedule while allowing scope to “float”. In other words, Agile efforts are managed primarily by managing scope.

Under an Agile approach, there are no surprises. We have a certain amount of budget and time to spend developing software capabilities. We continuously verify (test) the solution as we build it to ensure we are building things right and demonstrate and release functionality often to ensure we built the right things. Since we build and deliver solutions iteratively and incrementally, customers and end users get valuable business or mission capabilities sooner.

For as long as we have enough budget and schedule, we have the option to continue developing functionality or stop after realizing enough value. We also have the option to pivot to a different solution approach or cancel the solution altogether. When budget and schedule run out, we can choose to invest more on the solution based on demonstrated functionality and customer and end-user feedback.

Overemphasizing Control

Enforcing the constraints of the Iron Triangle causes project management to implement heavyweight management and reporting processes. These processes are attempts to lower risk by increasing control. Overemphasizing control slows software development and decreases the flexibility necessary to tackle risks and challenges. On the other hand, underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress. An optimal balance between control, flexibility, and speed requires empowering technical contributors to plan their own work based on sponsor, stakeholder, customer, and end user needs and enterprise technical constraints. The main reason for this is the inherent complexity of software systems.

High-performing teams are empowered teams. They take on or participate in many duties traditionally left to project management: Devising work plans, decomposing work and deliverables, monitoring task and reporting progress, and meeting commitments.

Software Development’s Inherent Product Management Bias

Software is never finished. We’ve moved away from delivering discrete, standalone software package products (think Windows 95) to continual delivery of new software functionality and bug fixes via updates distributed over the internet. Even in organizational IT and enterprise system integration efforts, development never truly finishes. If any solution or product is to survive, it must adapt to meet changing customer needs while maintaining quality and performance.

Also, software is infinitely changeable. Since software is abstract, we can add and modify it at will with much less effort and expense than physical solutions or products. Thus, we don’t see the same level of resistance to updating software solutions as we see with physical products. The very nature of software solutions makes them likely to continue changing and evolving long after initial development.

Thus, managing the development and evolution of software solutions as projects that start and stop does not make sense. All software solutions go through the stages of the Product Lifecycle.

The Product Lifecycle

The Product Lifecycle includes the phases all products go through during their useful lives: from when they are first conceived, to when they are retired from the market or their mission domains. This cycle focuses on the performance of the product in its intended market or mission domain. All products, including software solutions, commercial or otherwise:

Start out as an idea developed into an initial version of a releasable product
Are introduced / released to their intended consumers or user bases
See their market or user base expand, if successful. This phase tends to drive the most product changes that keep the product relevant and/or profitable
See an eventual stabilization or flattening in customer use, sales, or revenue growth as the product’s market or mission domain matures
See their market or mission domain decline as it becomes saturated or customers move on to new solutions
Are retired when they cease to be profitable, effective, or relevant

Projects Incur Wasteful Overhead

Traditional project management’s focus on projects is wasteful. Starting and stopping projects incurs significant overhead. Examples include:

Contracting activities (and acquisition activities, for government projects) – Finding contractors / vendors, putting them on contract, monitoring performance, “Color of Money” concerns, etc.
Ramping up new employees or vendors to be productive – Accesses, equipment, software tools, training (formal and on-the-job), etc.
Ramping down employees or vendors as projects end – Removing accesses, returning equipment, managing software licenses, etc.
Not having the flexibility to easily terminate failing projects or projects considered no longer necessary or desirable – It is much cheaper and easier to cancel a project after spending $10 million than after spending $100 million

Agile’s Inherent Product Management Bias

So, if we should manage software development as product development efforts, rather than as projects, what does that look like? It looks like Agile software development. Agile software development in general, and Scrum specifically, have an inherent product management bias. Table 2 below shows how Scrum fulfills the product management duties listed in Table 1:

Conclusion

In my experience, the single biggest reason why so many Agile software development efforts fail to achieve the benefits of Agile is the conflict between traditional project management thinking and Agile’s inherent product management approach to software development. This is not just my opinion, it is a growing realization Lean-Agile circles[i].

Today, business and mission requirements change too quickly for slow-moving predictive planning and management approaches. To meet the challenges brought about by the quickening pace of technology, we must leverage flexibility and control to achieve speed while maintaining quality. This requires a shift from a project management to a product management mindset.

[i] https://www.scaledagileframework.com/lean-portfolio-management/

Let us know what you think!!!

Fixed-Price Contracts Can be Agile

Fixed-price contracts don’t have to kill agility.

Table of Contents

Most fixed-price contracts are inherently anti-Agile. It is not because they set a budget ceiling for a project. I and many others argue that budget and schedule constraints actually enable Agile project planning. The issues associated with fixed-price Agile software development contracts lie in how project management determines and enforces scope, budget, and schedule constraints.

Predictive vs. Adaptive Planning

Most fixed-price contracts ignore a fundamental disconnect between traditional project management and Agile practice. Traditional project management planning is predictive while Agile planning is adaptive. Fixed-price contracts require planners to define the three constraints of the Iron Triangle – scope, cost/budget, and schedule – upfront.

In traditional software projects, project management closely tracks task progress towards scheduled milestones and the associated budget burn rate. There is little room to change project plans when things go awry. Also, projects lose the flexibility to change plans based on lessons learned and discovery of new requirements during development.

In contrast, Agile planning “breaks” the Iron Triangle by allowing scope to “float” within budget and schedule constraints. This means that given a fixed budget and timeframe, project sponsors, stakeholders, and software development teams collaborate to determine what to build during development. We control Agile software development projects primarily by managing scope.

We determine what viable and valuable capabilities to develop, deploy, and release within budget and time constraints. As long as project sponsors and stakeholders work with development teams to continually refine and prioritize requirements, teams will deliver the most important product / system / solution features at appropriate levels of quality and complexity. In Agile projects, sponsors have the flexibility to:

Continue developing the current implementation as planned

Pivot to a different implementation approach

Stop when enough useful functionality is developed and fielded

Cancel development altogether if necessary

Control vs. Flexibility

Fixed-price contracts are one way traditional project managers attempt to mitigate project risk. Government agencies prefer fixed-priced contracts because they shift project risk onto vendors. Vendors bid based on solution requirements stated in requests for proposals (RFPs). It is up to the vendors to ensure their proposals accurately reflect the cost of satisfying requirements, within the specified timeframe, and at a competitive price that allows them to make money.

Since no one can predict the future, vendors often do the following:

Pad their proposals and project estimates

Underbid with the expectation of submitting change requests or Engineering Change Proposals (ECPs) later

Challenge any interpretation of requirements that may increase project scope (scope creep)

Vendors are disincentivized to accept changes in requirements that may perturb the plan and cost them margin.

Meanwhile, project sponsors worry they will not get what they paid for in terms of functionality and quality. Those worries often translate into burdensome tracking and reporting requirements.

Agile provides opportunities to inspect and adapt solutions and their development. This transparency is Agile’s safeguard against scope creep and project and solution underperformance.

Unfortunately, traditional project managers often forgo opportunities to define and validate solutions during development. Instead, they favor traditional project management tracking and reporting. They focus on tracking tasks completed rather than validating value delivered. Even the misnamed concept of “Earned Value Management” (EVM) assumes a deliverable’s value during development equals the budgeted cost of the effort expended on it, regardless of its ability to provide business or mission value.

The Agile Alternative

Instead of attempting to manage all three Iron Triangle constraints as variables, keep cost and timeframes fixed while managing scope. Rather than tracking task completion, deliver working functionality early and often to validate that development teams built the right things in the right way. This places responsibility for defining the solution or “product’ squarely on project sponsors, with help from stakeholders and development teams. Traditional project managers often struggle with this approach because it is a product management approach rather than a project management approach.

Conclusion

Fixed-price contracts do not have to run counter to Agile practices. They can be written to allow project sponsors and stakeholders to define what business or mission capabilities they need, within fixed cost and schedule constraints.

Doing so encourages developing solutions by starting small and building on successes. After all, it is much easier to cancel a $10 million project after six months than a $100 million dollar project after two years. This Agile approach to fixed-price contracts ensures that something of value comes from the investment while opening the door to future investments based on business or mission success.

Let us know what you think!!!

Managing Software Project Scope: WBS vs. Product Backlog

Both decompose project scope in very different ways.

Many organizations steeped in traditional project management culture struggle to adopt Agile’s product management approach. One of the biggest cultural stumbling blocks is the difference between how traditional project management and Agile treat project scope. This is best exemplified by the differences between the Work Breakdown Structure (WBS) and Scrum’s concept of the product backlog. This article describes both tools, compares and contrasts them, and makes the case for not conflating these two methods of accounting for project scope.

What is a WBS?

The PMBOK® Guide—Third Edition defines a WBS as:

“A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.”

PMBOK® Guide—Third Edition

A WBS is a planning tool that helps identify, document, and present the total scope of a project. Scope is one of the three project management constraints colloquially known as “The Iron Triangle”.

The Iron Triangle represents how scope, schedule, and level of effort/resources act as mutually-dependent project constraints. Traditional project management attempts to predict most, if not the entire, project scope prior to project execution. Later, planners estimate the level of effort required to complete planned tasks and deliverables and build a project schedule based on those estimates. The resulting three values feed calculation of project cost.

WBS Structure

A WBS is most often depicted as a hierarchical tree. Every node in the tree is called an element.

Click to Expand — Figure 2: Basic WBS Structure

Depending on the type of WBS hierarchy created, project scope may be organized in terms of:

Project/program activities necessary to deliver deliverables (Verb-Oriented)
Product components that make up a deliverable (Noun-Oriented)
Time-bound phases of the project plan
A mix of the previous three types

The root of the tree (WBS level 1) represents the entire scope of the project or product deliverable. From there, the main branches/elements of the tree (WBS Level 2) are structured in accordance with one of the four types of WBS hierarchy types listed above.

WBS Decomposition

The tree expands as higher-level elements are decomposed into smaller constituent elements or components. Each element represents 100% of planned work and deliverables for that element. Child elements collectively represent 100% of the scope represented by their parent. Decomposing across elements just enough to facilitate project scope definition, without over-specifying the project or solution, while accounting for the entirety of project scope, is an art honed by experience.

Mapping to schedule and Resources

At the lowest level of each branch of the WBS hierarchy are work packages. Work packages map project scope (deliverables and activities) to project schedule. A work package includes schedule activities and milestones required to complete the associated deliverable or work element/component. In turn, control accounts map work packages to project budget (cost), facilitate the roll up of activities and milestones into an integrated schedule, and allow planners to assign specific resources (e.g., people) to specific elements of the WBS hierarchy.

Another artifact that ties the scope represented by the WBS to project schedule and resources is the WBS dictionary. The PMBOK® Guide—Third Edition defines a WBS dictionary as:

A document that describes each component in the WBS. For each WBS component, the WBS dictionary includes a brief description of the scope or statement of work, defined deliverables, a list of associated activities, and a list of milestones. Other information may include responsible organization, start and end dates, resources required, an estimate of cost, charge number, contract information, quality requirements, and technical references to facilitate performance of the work.

PMBOK® Guide—Third Edition

The WBS dictionary for figure 3 above may look something like this:

Types of WBS Hierarchies

Let’s delve a little deeper into the different types of WBS hierarchies.

Project Scope WBS

A project scope WBS decomposes the project work or activities necessary to produce deliverables or products. The first word of each WBS element name is a verb, such as, design, develop, test, etc. In figure 4 above, the project is organized by Software Development Lifecycle (SDLC) phases (Define, Design, Develop, and Integrate & Test) and includes the project management work necessary to orchestrate the work.

Product Scope WBS

A product scope WBS defines project work in terms of the components (physical or functional) that make up a deliverable or product. In this case, the first word of each WBS element name is a noun, such as, Module A, Subsystem B, Aircraft Engine, Fuselage, etc. Since each element represents a part of the overall product, this WBS type is sometimes called a “Product Breakdown Structure (PBS)”.

Time-Phased WBS

Large-scale projects can take years to complete. In such cases, it is reasonable and advisable to break up project scope and schedule into discrete phases. A “time-phased” WBS breaks up the project into major phases instead of activities. Rather than planning the entire project upfront, planners follow a “rolling wave” planning approach in which they plan the upcoming phase in detail while postponing detailed planning for later phases. Rolling wave planning affords the opportunity to improve current plans based on lessons learned in previous phases. It also provides a measure of flexibility to deal with changing project realities.

Hybrid WBS

Elements from the three other WBS types can be combined to create a “hybrid” WBS. Defense materiel project planners frequently use this type of WBS. Such projects tend to be long-lived, so time-phased branches may be included. Product-based branches scope complex products/deliverables. For activities that map to specific activity phases (e.g., SDLC phases), project scope elements are appropriate. A hybrid WBS may include project or program activities outside the scope of creating physical or functional product components or managing their creation. Examples of such activities include training, operations & maintenance, and facilities management.

WBS Type Comparison Chart

I summarize the WBS hierarchy types in the table below:

Agile Value Delivery

Before discussing product backlogs, I need to explain how Agile software teams deliver useful capabilities.

Agile software teams deliver iteratively and incrementally. They release valuable increments of software functionality over the entire development effort. These increments are “production ready” or “potentially releasable” software capabilities that customers and end users can start using right away. While not everything released by Agile teams must be user facing, they avoid releasing individual system components or portions of components that do not deliver real business or mission value on their own.

Solutions built by Agile teams grow and evolve over time. Each and every increment delivered is designed to work with all other increments, past and future.

Thus, Agile releases are primarily feature-based, not component-based. Rather than delivering system components, Agile software teams strive to deliver features. Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users.

What is a Product Backlog?

A product backlog is an ordered queue of deliverables. The term product backlog is most associated with the Agile framework called Scrum. According to the Scrum Guide, the product backlog:

…is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

https://www.scrumguides.org/scrum-guide.html

In this definition, the “product” is whatever the Scrum Team develops and delivers (application, system, solution, documentation, reports, etc.). A product backlog is used to track product deliverables.

As depicted in figure 9 below, Scrum teams take into account multiple considerations when ordering product backlog items.

Learn more about ordering product backlogs.

Product backlog items represent features. Scrum teams decompose bigger features into smaller ones to better manage their development.

The highest-ordered items are most ready for implementation. The Scrum Team refined them well enough to implement them. Lower-ordered items are increasingly less ready for implementation the further down the product backlog they rank.

Comparing & Contrasting WBS vs. Product Backlog

Having level set what a WBS and product backlog are, I now discuss the similarities and differences between them.

Similarities

Of the four WBS types discussed in this article, the PBS is most like a product backlog. Both are product scope-focused and decompose larger deliverables into smaller ones.

Neither a WBS or product backlog depict dependencies between elements or items. The main artifact used to show dependencies between work activities and deliverable milestones in traditional project management is the project schedule. User story maps help organize Scrum product backlog items (epics and user stories) based on workflow and interface dependencies.

Differences

The main difference between WBS hierarchies and product backlogs is that the WBS is a tool for linking together project scope with the other two Iron Triangle constraints: schedule and level of effort/resources. A product backlog is strictly focused on tracking and ordering product scope.

Modern Agile productivity tools like JIRA allow development teams to document the work they perform, how long it takes them to do it, etc. However, that information is collected after developers pull the highest priority items from the product backlog and begin work. The product backlog is neither a repository for nor a source of work status information.

Another difference is that tasks and activities count as part of the scope represented by a WBS (e.g., project management tasks, meetings, reporting). While Agile software teams also deal with management and project overhead, those activities are not included in the product backlog. From an Agile perspective, those activities are not part of the product. They are necessary, yet ancillary activities to the work of developing, testing, and releasing software.

Finally, product-oriented WBS elements represent components while product backlog items represent features.

Disadvantages of Decomposing Product Scope into Components

Decomposing product scope into components has three major disadvantages:

Postponing integration and testing
Difficulty measuring progress
Formation of component team silos

Postponing Integration and Testing

In traditional software projects, there is often nothing valuable to test and evaluate, from a business or mission perspective, until most or all components are integrated into a cohesive solution. In traditional software projects, system integration is done infrequently, often occurring only once towards the end of development. Integrating components towards the end of a project often affords insufficient time to address problems.

Difficulty Measuring Progress

Traditional project management focuses on tracking tasks and activities and their level of completion (e.g., percentage complete). The rationale being that if everyone executes all necessary tasks and activities, on time, and in the right order, the project will proceed as planned. Therefore, project management’s job is to identify everything that needs to be done before the start of the project and enforce adherence to the plan.

The problem with applying this approach to software projects is that non-trivial software systems are significantly more complex than physical systems of comparable cost. This is because software systems can be developed and modified in infinite ways. As software systems evolve to serve growing numbers of requirements from growing user bases, their complexity increases, sometimes at a seemingly exponential rate. No amount of predictive planning can overcome this natural slide towards entropy.

There is also the issue of quantifying how much actual progress has been made. What is the difference between a component being 75% complete vs. 95% complete? If we have to wait until it is 100% complete and integrated into the larger solution before we can test and validate it, there is none.

Agile planning is adaptive, with short project planning horizons. Software development teams achieve fast and frequent releases by keeping releases small. Planning and releasing this way allows for more opportunities to test and validate deliverables and to fold lessons learned into ongoing planning. Best of all, the measure of project progress is delivery of valuable capability to customers and end users rather than arbitrary estimates of completion rates.

Formation of Component Team Silos

Each WBS element maps to a set or resources (one or more teams) that do the work. Establishing development teams for specific solution components often stifles cross-team collaboration and creates productivity bottlenecks.

For example, project management forms a dedicated database team to deliver a system database identified as a WBS component. The result is that the team’s allocated hours and skillset are segregated around delivering a single component. Often, the inefficiencies of managing dependencies between component teams outweigh the efficiencies gained from component team specialization.

Forming teams around system features is a staple of Agile software development. While component teams are sometimes necessary in Agile software development efforts, the default bias is towards forming feature teams. Under feature teams, system components form and evolve incrementally and iteratively, one feature at a time. Value delivery no longer depends on delivering the entire system. Instead, value delivery occurs one release at a time throughout development.

Agile Breaks the Iron Triangle

To achieve project agility, Agile breaks the Iron Triangle by making project scope variable while fixing resources and schedule. This involves shifting our thinking about managing projects:

The most optimal solutions reside in the nexus of value, cost-effectiveness, and timeliness:

Agile projects control scope and ensure teams satisfy requirements through ongoing planning and collaboration between development teams, project sponsors, stakeholders, customers, and end users. Sponsors control budgets and approve project roadmaps; stakeholders, customers, and end users work with development teams to define solutions; and development teams plan and build functionality within those constraints. The advantages of controlling projects primarily through managing project scope are:

Not sacrificing quality in favor of adhering to all three constraints of the Iron Triangle.
No budget or schedule surprises (since budgets and schedules are essentially fixed)
Basing project decisions on the actual business or mission value delivered and team performance rather than alignment to detailed (and possibly obsolete) plans

Conclusion

At the heart of the differences between traditional project management and Agile is the fundamental difference between project management and product management. Project management focuses on managing tasks and activities to ensure they complete on schedule and on budget. Product management focuses primarily on managing the product.

Many project and program managers are unaware of this difference. Implementation of Agile practices corrupted by traditional project management biases often leads to failed projects. Attempting to structure product backlogs like WBS hierarchies is one manifestation of this misalignment between traditional project management and Agile mindsets.

Let us know what you think!!!

Three Reasons Business Analysts Need Product Owner Skills

Product ownership skills are key to increasing your marketability and versatility

Note: This article follows the capitalization of Scrum terms followed in Scrum.org’s Scrum Guide.

Table of Contents

In a world that prizes specialization, business analysts (BAs) are expanding the profession. As organizational complexity grows and the pace of change quickens, businesses, non-profits, and government organizations are transforming themselves to better meet those challenges. The quest for business agility is compelling organizations to abandon traditional project management approaches to information systems development in favor of Agile. To remain effective and marketable, BAs are adding Agile practices and techniques to their skillsets.

For many BAs, their understanding of Agile is limited to the mechanics of a particular Agile approach, such as Scrum. Often, their first formal introduction to Agile is some form of Scrum Master training.

Scrum Master training is taught primarily from the perspective of supporting the work done by software development teams through application of Agile principles and Scrum practices. Scrum Master training alone does not do enough to address the knowledge and skills most important to BAs supporting Agile projects: how to bridge the work of Agile teams with sponsor, stakeholder, customer, and end-user needs. Those skills are at the core of Scrum product ownership.

Beyond the fact that Agile has become the preferred way of structuring software development projects across a growing number of organizations, this article discusses three reasons why Scrum product ownership is an essential skillset for any BA.

Reason #1: Business Analysis Aligns with Product Ownership

Of the three roles identified by the Scrum framework (Scrum Master, Product Owner, and the Development Team) the Product Owner (PO) is responsible for ensuring that the work performed by the Development Team delivers valuable business or mission capability, cost effectively, and in time to be valuable. As such, the PO and BA roles share many responsibilities.

The International Institute of Business Analysts (IIBA) considers the PO job title to be one of many that fall under the BA umbrella:

Business Analyst Job Titles — Business Analyst overlaps with many job titles, including Product Owner

A comparison of job responsibilities for both roles further highlights how closely related they are:

Business Analyst vs. Product Owner Roles — Business Analyst vs. Product Owner Responsibilities

Reason #2: Scrum’s Product Management Orientation

A major difference between Scrum and traditional IT project management is Scrum’s product management/development orientation. Scrum’s terminology is indicative of this product management bias with terms like Product Owner and Product Backlog. From the perspective of Scrum, software solutions are products. While the focus of traditional project management is on managing people, schedules, and activities, Agile in general and Scrum in particular focus on managing the product.

A good way to illustrate the differences between product management vs. project management mindsets is to compare the core functions performed by product managers and project managers. While their work often overlaps, their primary responsibilities compare as follows:

A product management approach to developing software solutions changes how we define software solutions. For example, in traditional software projects, functional requirements are decomposed and written in ways that decouple planned functionality from expected business or mission outcomes. They are written from the perspective of the system (e.g., “The system shall…”). In Scrum, requirements, typically written as user stories, are written from the perspective of the user and clearly link desired outcomes with planned capabilities:

As <a user or role> I want <some capability> so that <desired outcome>

This user-centric approach to requirements supports Agile’s iterative and incremental definition, development, and delivery of software solutions. Customer centricity is a key component of Scrum’s product management approach. That approach aligns well with the goal of business analysis: enabling organizational change by defining business needs and recommending solutions that deliver value to stakeholders.

Reason #3: No Formal Role for Traditional BAs on Scrum Teams

As I stated earlier, Scrum identifies three roles: Scrum Master, Product Owner, and the Development Team. While all three roles collaborate to form a cohesive “Scrum Team”, they each have specific responsibilities. The responsibilities that most closely align with those of a BA belong to the PO.

However, there is one very big difference between the PO role and that of a BA. The PO is ultimately responsible for the success or failure of the product. As such, the PO is empowered to make decisions about the direction of the product vision. In other words, the PO decides what the product will ultimately be, how it will function from a business or mission perspective, and what business or mission capabilities it will include.

To be clear, the PO does not make decisions about how to develop the product. That is the responsibility of the Development Team.

The PO does not make product decisions in a vacuum or by behaving like a traditional project manager. Instead, the PO works alongside the Development Team in defining the “product” based on input from an actively engaged stakeholder community (i.e., sponsors, stakeholders, customers, and end-users).

For their part, Development Team members collectively manage their own work, determine technical approaches, develop their own estimates, report their progress, and help define the functionality they build. This contrasts with traditional project management practice, in which management is responsible for defining what to build, breaking down and assigning work, developing plans and schedules, and reporting progress. Scrum Development Teams are self-organized.

This means that Scrum Team developers develop their own requirements, primarily through collaboration with the PO, but also as they collaborate directly with technical and business/mission-facing members of the product’s stakeholder community. The old saw about developers not caring about business requirements and being fixated on implementing technology does not apply to Scrum teams. Developers are expected to be user-centric too and to think in terms of improving the product, not just delivering software components.

So, if there is no formal role for BAs in Scrum, how should they participate and contribute? There are three BA participation options: 1) As a Scrum Team member; 2) As a proxy to the PO; 3) As the PO.

Business Analyst as Scrum Team Member

The first option would include the BA as a member of the Scrum Team. The BA would then work with the team to refine the Product Backlog. The issue here is that the entire Scrum Team participates in backlog refinement. Therefore, the BA would need to contribute through additional duties such as facilitating stakeholder requirements elicitation, creating technical documentation, or explaining business requirements to testers. Some BAs may consider this a less than desirable fit since their attention would be diverted, to some degree, towards activities outside their traditional role.

Business Analyst as Proxy to the Product Owner

This is the least desirable of the three options and should be avoided. In this option, the BA is a “go between” for the Scrum Development Team and the PO. Since the BA is not empowered to make decisions about the product, he/she must gain approval from the PO. This turns the BA into a time bottleneck and deprives the Development Team and the PO of the close interaction required to make the Scrum Team work as intended. Eventually the Development Team may learn to discount the input the BA provides since it may be overruled by the PO at any time.

Business Analyst as the Product Owner

This is the best option of the three. As I discussed earlier, the PO role carries more responsibility and a larger scope than the typical BA role, however, it also shares many responsibilities. While not every BA will necessarily be willing or able to make the transition, it is definitely a workable option.

Conclusion

BAs typically work in or consult for mid-to-large-sized organizations, where the size and complexity of software solutions warrants employment of BAs. While a growing number of these organizations are shifting or have shifted towards Agile, many have not or are slow to shift. As a result, many BAs possess experience and skillsets aligned with a traditional project management rather than with Scrum’s product management approach to IT solutions development.

As a BA, acquiring Scrum product ownership skills can only help your career by making you more marketable and versatile. Regardless of the type of projects you contribute to, the analytical and leadership skills you will gain will help you become a more effective BA.

Let us know what you think!!!