Category: Product Development

MVPs, MMFs, and MMPs Untangled

Confused about MVPs, MMFs, and MMPs? Time to set things straight.

Agile software development is an evolving discipline.  The authors of the “Agile Manifesto” and its associated “12 Principles of Agile Software” distilled commonalities across a number of Agile approaches into a simple, complete, and cohesive set of values and principles.  Defining Agile as a set of values and principles to align to, rather than as a methodology to follow, encouraged creation of new software development approaches and best practices.  As long as new approaches and practices align with the Agile Manifesto and 12 Principles, we can consider them Agile.  This decentralized approach to Agile adoption democratized Agile, allowing us to adopt existing approaches, tailor them, reject them, or create our own.

Agile theory and practice are firmly rooted in empiricism.  Agile shares this characteristic with Lean management and product development.  As a result, many Agilists (knowingly or not) have incorporated Lean and product development concepts into Agile approaches. 

One of the better known product development influences on current Agile thinking and practice is the concept of the Minimum Valuable Product (MVP).  MVPs dovetail nicely with Agile empiricism and value delivery.  However, competing definitions of MVPs, as well as popularization of other product development concepts such as Minimum Marketable Features (MMFs) and Minimum Marketable Products (MMPs), have caused confusion across Agile software development efforts.  This article explains the definitions of each of these concepts and how they align with Agile software development.

Rationale Behind MVPs

Product development is the process by which product teams bring products to market, from original idea to market release and beyond.  Successful products solve problems important to customers in target markets, in ways that satisfy their needs and desires, and at the right price. 

An MVP is a simple and quickly produced version of a product that allows product developers to validate their assumptions.  MVPs help determine market fit and provide useful feedback that further informs product development.

MVPs are ultimately about lowering risk.  The biggest risk in any development effort is building the wrong thing.  In the commercial space, this translates into creating something the target market is unwilling to pay for.  In organizational IT this risk manifests as system implementations that do not meet the needs of the Stakeholder Community (i.e., sponsors, stakeholders, customers, and end users).  Building the wrong thing negates all of the time, effort, and expense spent developing the product.

Agile Software Development and MVPs Align

Continual product validation is baked into Agile approaches such as Scrum.  Agile teams continually validate that they are building the right things while verifying (through continuous testing) that they are building them the right way.  They also deliver valuable software functionality iteratively and incrementally.  Doing so affords development teams multiple opportunities to validate solutions with relevant Stakeholder Community members throughout development.  Stakeholder input and lessons learned inform ongoing adaptive planning, requirements definition, design and implementation approaches, and development practices.  Use of MVPs to validate solutions aligns with this empirical approach to software development.

Confusion over MVPs

The main source of confusion around MVPs has to do with whether an MVP is the first version of a marketable product or a vehicle for validating product assumptions and learning about target markets and customer needs.  The first definition seems to align with the word “product” in MVP while the second makes MVPs sound more like prototypes.  The root of the problem is that both definitions are correct depending on the type of product and market the product team targets.

Frank Robinson’s MVP Definition

Many attribute the coining of the term MVP to Eric Ries.  Ries is the author of the 2011 book, “The Lean Startup.”  That book popularized the term MVP.  However, Ries did not invent the term.  That credit goes to Frank Robinson, cofounder and president of Syncdev, a product and marketing development company.  He coined the term in 2001 and his company published a white paper in 2008 that defined an MVP as:

The right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.

https://web.archive.org/web/20090105160002/http://www.productdevelopment.com/howitworks/mvp.html, accessed 7/17/2022

Syncdev’s product development approach started with identifying a technically and financially “feasible” product idea.  The product team executed product development and marketing strategy in tandem.  The high-level product development journey looked like this:

Table 1: Syncdev Product Development Approach

It is important to emphasize that, under Syncdev’s approach, an MVP was the first version of the product.  It was the smallest version of a product customers were willing to pay for.  This approach was best aligned with selling business-to-business (B2B) or internal IT software systems to specific prospects.  It was not conceived for selling commercial products to larger market segments.  Those markets were better served by Eric Ries’ definition of the MVP.

Eric Ries’ MVP Definition

Eric Ries defined an MVP as, “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”[1]  This type of MVP is primarily focused on finding out what customers need and want based on a set of features most likely to attract paying customers.  In this case, an MVP could be a prototype, a mock up, landing page, or “minimal” version of the product.  As Ries stated:

As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.

https://libquotes.com/eric-ries/quote/lbq3c8m, accessed 7/17/2022

The objective here is not to develop a product to sell immediately but instead to learn more about customers and their markets while validating customer and product assumptions.  As product teams gain knowledge and understanding, they may develop additional MVPs of increasing complexity to test out additional ideas.  While an MVP may turn into a sellable product, that is not the focus of this type of MVP.

SAFe’s MVP Definition

The Scaled Agile Framework (SAFe) includes a definition of MVP that reads like a hybrid of Robinson’s and Ries’s definitions.  It supports validated learning as well as development of a potentially releasable software capability. 

As opposed to story boards, prototypes, mockups, wire frames and other exploratory techniques, SAFe’s version of the MVP is an actual product that can be used by real customers to generate validated learning.

https://www.scaledagileframework.com/epic/, accessed 7/17/2022

In the context of SAFe, an MVP is an early and minimal version of a new product or business solution used to prove or disprove an “epic hypothesis.”  Every SAFe epic attempts to validate a set of core assumptions that support its formulation.  As depicted in the diagram below:

Figure 1: SAFe Lean Start Up Cycle
  1. Every epic proposes an MVP
  2. The organization determines whether the software functionality developed under the epic proved the epic hypothesis
  3. If the associated software capability proves the epic hypothesis, then the MVP becomes the first released version of that product, solution, system, sub-system, etc. We may continue developing the epic or consider the epic done.
  4. If the functionality fails to prove the epic hypothesis, then we have the following options:
    1. Pivot away from the current MVP and formulate a new epic and associated MVP
    2. Cease further development of the epic or abandon it and its MVP all together

The SAFe Lean Startup Cycle treats epics as potentially releasable capabilities and aligns budget considerations with MVP development while incorporating validated learning.

Minimum Marketable Feature (MMF)

Adding to the confusion over MVPs is the concept of MMFs.  Mark Denne and Dr. Jane Cleland-Huang introduced this concept in their 2004 book, “Software by Numbers: Low-Risk High Return Development.”  They defined an MMF as, “A small, self-contained feature that allows companies to develop the product quickly while still delivering significant value to customers.”[2]

The value of MMFs is that they ensure that development teams deliver value as features.  Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users.  This contrasts with traditional software systems development which is organized around developing and integrating components.  A feature does not need to be user-facing.  For example, client systems that communicate with a backend service are that service’s customers.  Incrementally developing, updating, and delivering software systems as features aligns with Agile’s iterative and incremental value delivery.  You can learn more about the benefits of feature-based development here and here.

An MMF differs from an MVP in that it is a way of delivering value to customers and end users, not a validated learning technique.  It is the smallest amount of value we can market to customers and end users.  Nevertheless, delivering capabilities as features provides multiple opportunities to validate the product as it is built, deployed, and released, thus supporting Agile empiricism.

Minimum Marketable Product (MMP)

Many people use the term MMP interchangeably with MMF.  Some describe MMFs as individual features that collectively make up an MMP.  Regardless, the idea behind MMPs is to build and release the smallest feature or set of features we can market to customers and end users.

Another school of thought considers an MMP to be the smallest or simplest marketable version of a product resulting from the application of lessons learned from one or more previous MVPs.[3]  In other words, after validating product ideas via one or more MVPs, the product team develops a simple marketable version of the product based on previous validated learning.

Figure 2: From MVP to MMP

Conclusion

Every validated learning approach explained in this article emphasizes validating our assumptions about markets, customers, users, and products as quickly and frequently as possible.  We do not know how good our product idea is until actual customers and end users get their hands on it.  Until then, our assumptions and plans are just guesses / hypotheses in need of validation.

[1] https://leanstartup.co/what-is-an-mvp/, accessed 7/17/2022

[2] https://www.agilealliance.org/glossary/mmf/#q=~(infinite~false~filters~(postType~(~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’mmf))~searchTerm~’~sort~false~sortDirection~’asc~page~1), accessed 7/17/2022

[3] https://www.xdesign.com/blog/minimum-viable-product-vs-minimum-marketable-product-whats-the-difference/, accessed 7/18/2022



Stop Managing Software Projects

Manage Software Products Instead

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.

Table 1: Product Management vs. Project Management

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

  1. An overemphasis on managing the triple constraints of the “Iron triangle” to the detriment of technical execution, product quality, and value delivery
  2. 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.”

Figure 1: The Iron Triangle

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.

Figure 2: Waterfall, Agilefall, and Agile Release Frequencies

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.

Figure 3: Pivot or Persevere

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

Figure 4: 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:

  1. Start out as an idea developed into an initial version of a releasable product
  2. Are introduced / released to their intended consumers or user bases
  3. 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
  4. See an eventual stabilization or flattening in customer use, sales, or revenue growth as the product’s market or mission domain matures
  5. See their market or mission domain decline as it becomes saturated or customers move on to new solutions
  6. 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:

Table 2: How Scrum Fulfills Product Management Duties

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/



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”.

Iron Triangle
Figure 1: 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.

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.

Figure 3: WBS Hierarchy with Control Accounts

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:

Table 1: WBS Data Dictionary Template Example

Types of WBS Hierarchies

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

Project Scope WBS

Figure 4: Project Scope (Verb-Oriented) 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

Figure 5: Product Scope (Noun-Oriented) 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

Figure 6: 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

Figure 7: 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:

Table 2: WBS Hierarchy Type Comparison Chart

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.

Figure 8: Waterfall vs. Agile Value Delivery

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.

Figure 9: Product Backlog

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.

Figure 10: WBS vs. Product backlog

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:

  1. Postponing integration and testing
  2. Difficulty measuring progress
  3. 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:

Table 3: How Breaking the Iron Triangle Shifts Thinking about Managing Projects

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

Figure 11: The Optimal Solution Space

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.



The Five Most Important Factors in Prioritizing Product Backlogs

Achieve effective Product Backlog ordering by optimally balancing five competing factors

Note: This article includes a video detailing how to calculate Weighted Shortest Job First (WSJF) values.

Product Backlog “prioritization” is a popular topic in Agile and Scrum forums.  It seems like a simple concept.  Teams prioritize the most valuable or important product backlog items or features and begin work on the highest priority items.  However, teams quickly discover that there is much more to prioritizing backlog items than that.

The difficulty boils down to determining what is more or less valuable or important when every item addresses valid needs.  How do we deal with the ambiguity of determining what is “most valuable” or “more important”?  How do we account for dependencies and other factors that influence what we build and when? How do we do so in a consistent, non-biased way that ensures delivery of valuable solutions, cost effectively, and in time to be most valuable?

Understanding Product Backlogs and their Refinement

For the uninitiated, before reading more about Product Backlog prioritization, I recommend reading our article on Product Backlog refinement.  At a minimum, understanding what a Product Backlog is and what Product Backlog refinement entails is crucial to understanding backlog prioritization.

Product Backlog refinement includes three main activities:

  1. Management of Product Backlog Items:  The creation, retrieval/tracking, update, and deletion of items

  2. Sizing of Product Backlog Items:  Relative size estimation of items

  3. Ordering:  Deciding in what order to address each item

In this article, I focus on Product Backlog ordering. This article does not apply to Sprint or iteration backlogs. Sprint backlogs are solely composed of user stories that take two to four weeks to complete. These items are likely too small in scope to warrant multi-factor prioritization/ordering schemes.

Prioritization vs. Ordering

As of 2011, the official Scrum Guide began defining the Product Backlog as “an ordered list” instead of a “prioritized” list.  Why was this changed and what is the difference between prioritizing a list and ordering it?

As Barry Overeem states in his Scrum.org article:

The focus on ordering (over ‘prioritization’) underscores the active role that the Product Owner continuously has to play in the ordering and reordering, of the work in a manner that maximizes value.

https://www.scrum.org/resources/blog/myth-5-scrum-product-backlog-prioritized

Simply stated, many factors influence Product Backlog Ordering, not just what is considered most important from a business or mission perspective.

Non-trivial software solutions service many sponsors, stakeholders, customers, and end users.  Their interests and priorities differ from, and sometimes contradict, each other.  It is the job of the Product Owner (PO) to fuse the various needs, wants, and perspectives of that solution community into one complete, coherent, and cohesive product vision.

There are also project and technical realities that must be taken into account when deciding what portions of a solution to build and deliver and when.  Examples:

  • Environments (e.g., development, integration, test, and production environments) may not be ready for use at a particular point in the project schedule

  • Key system dependencies (e.g., features, components, libraries, frameworks) may be missing or incomplete, thus impeding progress

  • The customer may add or take away project scope during the project

Business or mission circumstances, solution community needs, solution requirements, and project priorities change as the solution takes shape through iterative and incremental delivery of system capabilities.  A PO must lead continuous refinement and ordering of Product Backlog items to align with such changes.

Five Factors that Influence Product Backlog Ordering

The most optimal ordering of Product Backlog items is a balance between these competing factors:

  1. Business/Mission Value

  2. Cost/Size

  3. Time Criticality

  4. Technical Dependencies

  5. Risk Reduction/Opportunity Enablement

Figure 1: Product Backlog Ordering Factors

Factor 1: Business/Mission Value

How Agile defines value is different from how traditional project management defines it.  A simple definition of value is whatever solution sponsors, stakeholders, customers, and end users care about or makes them happy.  We discuss Agile’s concept of value further here.

A feature’s business or mission value is the value created by implementing the feature (e.g., revenue, cost savings, customer retention, prospective customers, future opportunities, mission accomplishment).  Features that map closest to the product vision likely rank highest for this factor.[1]

Factor 2: Cost/Size

It is common Agile practice to use relative sizing to estimate how much of a development team’s capacity will be consumed by a particular Product Backlog item.  One way Agile teams perform relative sizing is by assigning story points to Product Backlog items. Story points are heuristically-determined, numerical proxies representing the combination of perceived or estimated:

  • User story complexity, risk, and uncertainty

  • Level of effort required to complete the user story

This combination is often referred to as the “bigness” or “size” of a user story. The development team estimates user story points by “sizing” stories relative to each other. More complex stories typically require more time and effort to complete, thus earning more story points than less complex stories.

Just as there is a correlation between story complexity and size, there is also one between story size and the cost of implementing the story.  While not a perfect correlation, it is good enough to support efficient ordering of Product Backlog items.

Factor 3: Time Criticality

How soon solution capabilities or system dependencies are needed also influences Product Backlog ordering.  Again, the goal of Agile is to deliver valuable capabilities, cost effectively, and in time to be valuable.  Delivering a capability before it is needed risks spending resources on something that may never be needed (YAGNY:  You Aren’t Gonna Need It!).  Delivering after it is needed risks delivering it too late to be valuable.

Agile achieves a “just-in-time” balance by constraining planning, development, and release scope to fit within relatively short time frames (iterations/Sprints/releases) and delivering the highest ordered items first.  By waiting until “the last responsible moment” to define, develop, and release solution functionality, we avoid over-engineering solutions or losing opportunities to provide value.

Factor 4: Technical Dependencies

Software solutions are inherently complex.  As such, their technical components often rely on other components to function.  For example, multiple features may require a database backend to store data and state.  Product Backlog ordering must take into account these dependencies as solutions grow and evolve.

Factor 5: Risk Reduction or Opportunity Enablement

Software system complexity introduces technical and project risks and opportunities.  Diligent backlog refinement spreads risk management actions across the entire software development effort.  For example, a team may choose to tackle riskier Product Backlog items earlier.  Another may identify an opportunity to shorten the schedule by accelerating delivery of a dependency common across multiple parts of the solution.  This differs from traditional project management efforts that, even when risks and opportunities are identified early, tend to accumulate risks, address them after they become issues, and miss opportunities.

Prioritization Techniques

Backlog ordering is the art of balancing these five factors to best facilitate Agile development and delivery of software solutions.  The three prioritization techniques briefly discussed in this section are not specific to Agile or Scrum.  They are well-known product management techniques. 

The first two, the Kano Model and the MoSCoW Method, have narrow perspectives and reduce business or mission value considerations to simplistic categories.  The third technique, Weighted Shortest Job First (WSJF), takes into account all five factors discussed in the previous section.

Kano Model

Professor Noriaki Kano developed the Kano Model in the 1980s.  The model categorizes product features according to customer needs and expectations.  In other words, what will satisfy or please customers?  Many versions of the model exist.  The original classifies items using five categories: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse.

The Kano Model is most useful in organizations that create mostly “Must-Be” features: Features expected or taken for granted by customers.  However, products should include “Attractive” and “One-Dimensional” features to succeed in the marketplace.

Table 1: Kano Model Categories

Using this technique, the Product Backlog would include items from every category except “Reverse”.  Releases and Minimum Viable Products (MVPs) would include some set of items from those categories.  As MVPs grow and evolve, more items from across those categories would be added.

The problem with this approach is that it narrowly focuses on customer needs and expectations, which is one of many factors in gauging business or mission value.  However, Kano Model category definitions are useful in helping to shape thinking about the business or mission value of solution features.

MoSCoW Method

The MoSCoW Method, developed by Dai Clegg, has roots in Agile software development.  It is an acronym loosely based on the first letter of each of its categories: Must-Have, Should-Have, Could-Have and Won’t-Have.  The categories are defined from the point of view of what a product includes or offers vis-a-vis what customers or users want.  It answers the question, “What features will be included in the release or MVP?”

Table 2: MoSCoW Method Categories

Similar to the Kano Model, using this technique produces a Product Backlog that includes items from every category.  “Won’t-Have” items may either be postponed to future iterations or releases or dropped from the backlog altogether.

However, like the Kano Model, the MoSCoW Method focuses on one dimension of value.  In the case of the MoSCoW Method, it is determining which set of features best aligns with customer and end user expectations about the product/solution.

Weighted Shortest Job First (WSJF)

In his book, Principles of Product Development Flow: Second Generation Lean Product Development, Don Reinertsen explained the Weighted Shortest Job First (WSJF) prioritization model.  The model is used to sequence work in the most economically efficient way.

The folks at Scaled Agile Inc. explain a simplified version of Reinersten’s model here.  The simplified approach consists of two formulas:

Figure 2: A Formula for WSJF


Figure 3: Calculating Relative Cost of Delay

This simplified model is used in the Scaled Agile Framework (SAFe) to sequence (order) individual pieces of work or “jobs” (e.g., SAFe Features, Capabilities, and Epics) within their respective backlogs.

Unlike Reinertsen’s model, which uses monetary amounts to calculate Cost of Delay (CoD) and job duration, SAFe’s simplified model uses a relative sizing construct.  The construct uses a modified Fibonacci sequence as the basis for parameter values.  In calculating CoD, values for User-Business Value, Time Criticality, and Risk Reduction/Opportunity Enablement are assigned greater or smaller values relative to other jobs being ordered.  For job duration, “size” values are assigned to individual jobs.  Every job is sized relative to the other jobs being ordered.

We can create a simple table to track the relative values and calculate CoD and WSJF values:

Figure 4: WSJF Table

The following video provides more details on calculating WSJF values:

Calculating WSJF Values

The initial formulaic answer is a start to the ordering, not a final answer.  The computed sequence of Product Backlog items is adjusted to account for technical dependencies between them.

Teams may find it helpful to keep in mind the Kano Model and MoSCoW Method categories as they assign relative business or mission values to Product Backlog items/features and determine which items are ranked too low to include in the next Sprint or release.  Just remember that those categories do not represent the entirety of business or mission value.

We can use WSJF sequencing whenever Product Backlog we perform refinement.  Since Product Backlog refinement is a continual process, there will be future opportunities to apply WSJF.  Aim for “good enough” and trust that whatever issues surface later will be taken into account during the next round of Product Backlog ordering.

It is good practice to not let Product Backlogs grow too large.  Clearing items that may never be implemented is a good idea.  They can always be reintroduced later for ordering.  In the same vein, avoid ordering the entire Product Backlog.  Instead, focus on the next three Sprints or so.  Ordering items that may never rise high enough in the backlog to be implemented is wasteful.

Remember that Product Backlog ordering is an art, not a science.  As leads of this process, POs must leverage input from their Development Teams and solution community stakeholders and their own intuition and experience.

When Not to Employ WSJF

If the product backlog is small or mainly populated with user story-sized items, computation of WSJF values may be overkill. However, it is still advisable to take the five ordering factors discussed here into account when ordering product backlogs.

Leveraging User Story Maps

Scrum Teams can leverage user story maps to organize an ordered Product Backlog across solution workflow steps, Sprints, and releases.  Scrum Teams may use them in tandem with Product Backlogs to help identify dependencies as part of backlog refinement.  We explain user story mapping and provide an example here.

Capacity Allocation

The Product Backlog contains all of the solution requirements (e.g., epics and user stories) for which the Development Team may implement features.  If it is not in the Product Backlog, the Development Team does not implement it.  However, just because something is in the Product Backlog does not mean it will be done.

In light of this, it is often difficult for teams to balance delivery of business or mission value with work necessary to:

  • Implement back-end functionality or infrastructure that supports business/mission-facing functionality

  • Perform system maintenance to ensure overall system performance and quality

  • Address technical debt

  • Explore new requirements and technical approaches to address them

One way Scrum Teams achieve the right balance between different types of work is through capacity allocation.  Teams allocate their capacity to do work within an iteration/Sprint.  They allocate percentages of that timebox to specific types of work.  For example, a team may agree to devote most of the next Sprint to developing new business or mission capabilities, but allocate a percentage of that time to address technical debt and maintenance.  The team agrees to the types of work they will perform, and the percentages of the Sprint those work types will consume, based on current needs and constraints.

Conclusion

The key to effective Product Backlog prioritization is achieving an optimal balance between competing factors.  “Optimal” does not mean perfect. 

The WSJF technique provides a simple way of accounting for those factors.  WSJF is only a tool to help make decisions.  It is not a deterministic process that renders an exact solution. 

Arriving at a “good enough” Product Backlog ordering depends much more on effective collaboration between POs, development teams, and solution community stakeholders than on applying the techniques discussed in this article.  Ultimately, the quality of Product Backlog ordering depends on Agile’s empirical inspect and adapt approach to defining and executing work.

[1] Don McGreal and Ralph Jocham (2018).  The professional Product Owner: Leveraging Scrum as a Competitive Advantage 1st Edition. Scrum.org