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:

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

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!!!

The Real Price of Doing User Stories Wrong

Good user stories help deliver system scope in slices.

Most IT professionals are taught to think in terms of what a software system does or the functionality it presents to users rather than in terms of the business or mission outcomes users want to achieve. We see this first in the way requirements are written. In traditional software projects (i.e., Waterfall), requirements analysts and/or technical contributors write requirements from the perspective of the system. For example:

The system shall allow users to upload xyz reports

We could further refine and decompose this requirement (e.g., bulk uploads, user access (user interface or drop folder)) but the point here is that this traditional style of writing requirements puts the system front and center. On its own, this requirement provides no context to inform decisions about how best to implement this upload capability. The intent behind the need for an upload capability is missing.

This shortfall is typically addressed with additional requirements and documentation (e.g., CONOPs, design documents). Unfortunately, documentation is a poor way of communicating the business or mission context necessary to align proposed functionality and solutions to customer and end user needs.

User stories were supposed to fix this. After all, the most popular user story template places the user front and center:

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

So, we can re-write the requirement above as:

As a payroll analyst, I want to upload xyz reports so that I don’t have to manually input their contents.

We now know who needs the upload capability and for what purpose. The role of the user is important because it alludes to the kind of data we are talking about: payroll data. The outcome lets us know that the system is expected to do something with xyz report data, so this is not just an archival function. User stories are meant to be reminders of further conversations about what is needed, and this user story identifies the user to talk to, what they need, and why. This is enough information to get the conversation started.

More often than not, however, I see user stories written like traditional requirements:

As a system, I need to provide a way to upload xyz files.

Or worse:

As a developer, I need to build an xyz report upload capability.

The first example jettisons Agile user-centricity out the window in favor of a focusing on what the system will do. The second example makes it all about what the developer needs to do, thus making it a task, not a requirement.

So, what is the harm in all of this if the work gets done?

Click here for a more in-depth explanation of how to write user stories.

Bad User Stories Lead to Bad Value Delivery

Agile value delivery is primarily feature-based while traditional software development is component-based.

Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users. Agile projects deliver system scope iteratively and incrementally as features. A feature does not necessarily need to be user-facing. For example, client systems that communicate with a back-end service are that service’s customers.

One way to visualize how to slice system scope into features is the “Layered Cake” analogy. Like a layered cake, systems have multiple layers. The layers represented here make up a typical three-tiered web architecture where the bottom represents a datastore or database, the middle tier represents some kind of middleware, and the top layer represents a user interface. The entire cake represents the scope of the complete system.

System scope represented as a layered cake — The Agile “Layered Cake” Analogy

In a traditional project, you either get the whole cake at once or none at all. In Agile, we deliver slices of the cake. The customer consumes the cake a little at a time until they finish the cake.

Each slice of the cake or feature contains enough functionality from the three tiers to serve as a valuable feature. Every slice works with the slices baked before. The full scope of the system is defined, developed, and delivered “a slice at a time”. An increment is the sum total of all the slices or features delivered along the way. Thus, Agile development is iterative and incremental.

This analogy is overly simplistic since Agile teams do not slice features from a finished system. Instead they bake the cake one slice at a time. Along the way, the customer tells them what changes to the recipe they would like made. Also, we don’t know what the cake will look or taste like at the end. The customer may decide half way through baking that they have had enough or ask for more.

User stories are essentially features. A user story is a placeholder for a slice of system capability that can be delivered as a cohesive whole, integrated into the emerging system, and that delivers valuable business or mission capability. As we learn more about what is needed and the relative level of effort required to implement them, we refine, decompose, and size user stories. However, no matter the size, every user story represents a valuable business or mission capability.

Traditional requirements are aligned with how traditional software projects track and organize work. Requirements are allocated to system components that satisfy the requirement. This leads to the development, verification, and validation of individual system components. As a result, customers and end users must wait until enough system components are finished and integrated together into a cohesive system to deliver anything valuable, from a business or mission perspective. In traditional projects, this can take months or years.

This is important because the longer we wait to deliver useful capability to customers and end users, the later it will be before they can validate assumptions behind what we develop. Finding out that the solution is not what is needed or wanted at the end of a project is an unacceptable, yet common, occurrence in systems development. The faster and more frequently teams release functionality, the more opportunities we gain to incorporate what we learn into solutions as they are developed.

Conclusion

Agile-based approaches in general, and Scrum specifically, are ways of working that are based on a small set of principles. Take away any of those principles and you are no longer practicing an Agile approach. Agile is a user-centric approach to software development. Taking away user-centricity shifts the focus from frequent delivery of valuable business or mission capabilities to customers and end users to delivery of a finished system. Something as simple as how we write user stories is indicative of how well we have internalized Agile principles and understand the rationales behind Agile practices.

Have you seen examples of bad user stories like the ones covered in this article? What interesting examples of good or bad user stories have you seen? Tell us about your experiences here.

Let us know what you think!!!

Proposing a Definition of Agile

A definition of Agile applicable to all technical and non-technical projects that avoids discussing particular flavors of Agile or comparing Agile to Waterfall

Table of Contents

Definitions matter. They matter because they frame how we think about the concepts they define. In turn, how we think about concepts affects how we engage with and apply them. Definitions also help us communicate by allowing us to agree on the meaning of things. A clear, concise definition of a concept helps crystalize in our minds what we may otherwise perceive as a disorganized collection of ideas and facts.

A Definition of Agile

No official definition for Agile exists. Instead, Agilists have a set of tenets and principles guiding how they work. As long as work practices foster agility and do not run counter to Agile tenets and principles, they are considered Agile.

As Agile thought leaders and practitioners develop and share new ways of working, the most successful concepts and practices eventually become part of an informal canon of Agile best practices. No formal body exists to regulate or promote this innovation and knowledge sharing. Rather than a methodology, Agile is a community that shares norms, values, conventions, and, to some degree, identity.

This lack of a prescriptive definition for Agile is powerful. It provides practitioners a great deal of latitude in creating Agile approaches best aligned to their unique business or mission context. It gives people permission to try widely-adopted practices, modify them, or reject them based on their own experience applying them.

However, such latitude also brings differences of opinion over what is or is not Agile. Without a formal definition, answers to the question, “What is Agile?” often devolve into Scrum jargon-filled word salad or attempts to define Agile by what it is not, namely Waterfall-based systems development.

Another problem with the standard approach to defining Agile is that it relies too much on the two foundational principles of Agile: The Agile Manifesto and the 12 Principles of Agile. While a deep understanding of the two is essential for anyone attempting to work in an Agile way, they were written from the perspective of software developers who build IT systems. While adoption of Agile practices is growing in many industries outside of IT, the IT-centric focus of most Agile literature and instruction often leaves practitioners outside of IT unsure as to how to apply them within their own context.

Taking into account the limitations in how Agile is typically defined, while adhering to the Agile Manifesto and the 12 Principles of Agile, Agile Cheetah proposes the following definition of Agile:

An approach to developing complex systems and solutions in which work teams self-organize to deliver increments of value, within and across short iterations, guided by collaboration with and among other work teams, project sponsors, stakeholders, customers, and end-users.

Developing Complex Systems and Solutions

Agile development approaches are particularly well-suited for developing complex technical and non-technical systems and solutions of all kinds. Software solutions, in particular, are inherently complex because they can be developed and modified in an infinite number of ways. Software tends to grow in complexity as we add new functionality to address new requirements.

Traditional project management attempts to cope with this complexity through predictive planning while Agile takes an adaptive planning approach. Rather than attempting to identify and plan for all project tasks and milestones prior to project start, Agile planning breaks up the planning horizon into increments. This allows us to adapt plans when circumstances change, which they invariably do.

Adaptive planning is most appropriate when we lack enough certainty about business or mission requirements, solution approaches, or technology options to formulate a predictive plan. This is typically the case for most non-trivial software development projects. Agile’s iterative and incremental development and delivery model supports, and is supported by, adaptive planning.

Agile Teams Self-Organize

High-performing teams are crucial to tackling complex projects and the best Agile teams are high-performing teams. They are self-organized and capable and empowered to plan their own work and to collaborate effectively among themselves and with other teams, project sponsors, stakeholders, customers, and end users. This team-level independence, coupled with effective organizational and project governance, affords the flexibility necessary to thrive in less-structured, more uncertain environments. We give up administrative command-and-control bureaucracy, in favor of project flexibility and speed while keeping effective control over projects.

Delivering Increments of Value, Iteratively

Agile teams deliver value iteratively and incrementally. Every increment of value Agile teams deliver provides real business or mission value. Therefore, technical Agile teams are primarily feature-based as opposed to component-based. The traditional project management focus on delivering system components prevents system validation until all components are integrated into the completed system.

Agile Teams are Guided by Collaboration

What Agile teams create is determined through collaboration. Rather than deciding on a solution approach at the beginning and developing it with little to no input from sponsors, stakeholders, customers, and end users, those parties are actively engaged in defining requirements and validating system increments throughout development. This allows us to control scope by limiting what is built to what we know is currently needed and only to the necessary level of complexity. Achieving this level of collaboration requires Agile teams to work transparently by making information about their progress and the nature of what they develop openly and easily accessible. This way of working affords plenty of opportunities to inspect and adapt emerging solutions and team processes and practices.

Conclusion

Our wish is for this definition to help Agilists at all levels of experience explain what Agile is without resorting to talking about a particular flavor of Agile (Scrum, XP, Kanban, etc.) or engaging in comparisons between Agile and Waterfall. We expect our definition to simplify discussions about Agile across diverse audiences.

What do you think of our definition? How would you improve it? Do you have one you like better? Let us know by leaving a comment.

Let us know what you think!!!

The Agile Manifesto Explained

Setting the Record Straight

It has been almost 20 years since the publication of the Agile Manifesto and the 12 Principles of Agile that undergird it. During that time, the Manifesto has been a catalyst for profound changes in how we work, not in just software development, but across industries, governments, and nonprofits worldwide. Despite having attained such a level of influence, the Agile Manifesto is regularly misinterpreted in ways that undermine its intent.

This article sets the record straight. To do so, I walk through the Manifesto, line by line, provide context, and dispel a few myths. First, let’s read the Manifesto:

I’ll now go over each sentence starting with the first sentence:

We are uncovering better ways of developing software by doing it and helping others do it.

The Agile Manifesto and the 12 Principles of Agile together serve as the foundation of Agile practices. Rather than prescribing how to “do” Agile, Agile describes ways of working that steer away from a bureaucratic, command-and-control style of management to a decentralized, self-organized, and adaptive approach to building and delivering software systems.

Agile is a bottom up approach to software development in which developers and other technical contributors manage and continually improve the systems or solutions they develop as well as how they develop them.

Next, I skip to the last sentence:

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto states a preference for lightweight processes supported by face-to-face communication and sustained and meaningful engagement between technical teams, project sponsors and stakeholders, and customers and end users. It does not prohibit traditional project management practices such as communicating via documentation, instituting processes, leveraging tools, planning activities, and engaging in contract negotiations. Agile does not prohibit them because they are all necessary to some extent for any technical project to succeed. What Agile argues against is measuring progress based on accomplishing these internal project activities. Agile argues for determining project progress based on delivery of useful and valuable solution functionality and structuring both the work and how teams are organized to best incorporate changing requirements and lessons learned into emerging software solutions.

Now I continue with the first tenet:

Individuals and interactions over processes and tools

Software development is a creative endeavor. As such, people are at the heart of it. Tools and processes should support open and direct collaboration between people, not serve as substitutes for it. Using what are often described as “Agile tools” such as JIRA or VersionOne does not equate to working in an Agile way. Processes do not make up for a lack of training and support for those who do the work. A focus on improving people and the teams they work in yields much greater dividends than instituting processes and using tools.

The second tenet:

Working software over comprehensive documentation

The only real way to verify and validate solutions and gauge project progress is by developing and delivering working functionality. However, documentation is necessary, even in Agile projects.

The question is how much documentation is necessary and for what purposes? Too much documentation generates waste, slows down development, and fosters a false sense of progress. Too little documentation can lead to a loss of project knowledge, hampers the ability to manage projects, and may leave customers and end users without the information they need to use the resulting solutions.

There is no magic formula for striking the right balance. Collaboration between technical teams, sponsors, stakeholders, customers and end users will bring to light what documentation is necessary and to what level of detail. Just keep in mind that, when it comes to documentation, “less is more”.

It is also important to remember that documentation has inherent drawbacks. It is often out of date, its usefulness is often time limited, and it can be a source of confusion. Think hard over these drawbacks before engaging in documentation activities to ensure they are worth the effort.

The third tenet:

Customer collaboration over contract negotiation

Traditional project management focuses on contract negotiation and enforcement, often to the detriment of collaboration. While Agile projects are also bound by contracts, the focus is on fostering a win-win atmosphere of collaboration between those who develop and deliver software and those who sponsor and use it. Collaboration in Agile occurs across the entire software development lifecycle.

The fourth tenet:

Responding to change over following a plan

For most non-trivial software development projects, predictive planning is the wrong approach. Software is intangible and infinitely changeable. The opportunities to change a software system are as infinite as the number of reasons to change it. Predictive software development plans do not survive first contact with project reality.

Agile planning is adaptive planning. Project plans evolve as the project proceeds. This affords the flexibility to stop development when a solution satisfies the need or when the project is no longer viable. We also avoid over-engineering solutions and developing features that few, if any people, actually use. This allows us to control project cost and schedule, by managing scope, without sacrificing quality.

Conclusion

Saying that understanding the Agile Manifesto and its implications is necessary for conducting successful Agile projects and Agile organizational transformations is an understatement to say the least. Too many Agile implementations fail because people rush to learn and apply the mechanics of a particular Agile approach (e.g., Scrum, XP, Kanban) without understanding the principles behind it. Agile is not a methodology, a product you can buy, or a process. You cannot templatize and checklist your way into agility. Agile is a way of working born from a small set of principles. It is up to all of us to employ Agile best practices, and develop new ones, that align with those principles.

Let us know what you think!!!