Product ownership skills are key to increasing your marketability and versatility
Note: This article follows the capitalization of Scrum terms followed in Scrum.org’sScrum 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.
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 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:
Product Management vs. Project Management
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>
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.
“Agilish” software development projects, also known as “hybrid-Agile”, “Scrumfall”, or “Agilefall” projects, attempt to gain the speed and flexibility of Agile while enforcing traditional project management or “Waterfall” project controls. In Agilish projects, development teams engage in Agile “process mechanics” while other project stakeholders and contributors continue working under a Waterfall program construct. This mismatch in project approaches leads to what I call, “the worst of both worlds“:
Application of predictive planning and project controls (e.g., Earned Value Management (EVM)) that sap the agility out of Agile while;
Lacking detailed program baseline data necessary to measure project progress and apply project controls a la Waterfall
In part one of this blog series, I explained what Agilish projects are and why we should avoid them. In part two, I discussed the reasons why government Agile initiatives tend to move away from Agile principles and towards becoming primarily Waterfall projects with Agile practices added (Agilish). In this article, I discuss how to make Agilish projects more Agile when contractual and acquisition rules make an Agilish project management approach the only choice.
As I stated in the two previous articles, my perspective comes from years of working Agile projects for U.S. Federal Government clients. While many of the references are specific to that environment, equivalents exist at all levels of government, as well as in many private organizations, worldwide.
When Agilish is the Only Choice
In Agilish projects, software developers and other technical contributors are the only people “doing” Agile while everyone else continues working as before. U.S. Federal Government acquisitions and contracting culture make it practically impossible to “do Agile by the book.” The question is not whether federal software system projects will be Agilish. The question is to what degree can we make those projects approximate Agile?
We have two choices:
“Tailor” Agile to fit within existing
Waterfall-centric programmatic processes
Change programmatic processes to be more Agile
The first choice is the default for most Agilish projects. It typically results in failed Agile implementations corrupted by traditional project management biases. The second choice is harder but more likely to yield success. It requires acquisitions, contracting, and project management professionals to understand how modern software development practices affect their work and to leverage recent Agile-friendly changes in federal acquisitions regulations and policies.
Break the “Iron Triangle”
Firm-fixed-price contracts can work with Agile as long as we allow scope to “float”. In other words, keep budget and event milestones fixed while closely managing project scope. Rather than attempting to define a large number of detailed requirements, define a much smaller set of coarse-grained requirements to flesh out, decompose, and prioritize during development. Some degree of requirements ambiguity is necessary to achieve the Agile-style flexibility. This is the idea behind managing a Product Backlog in Scrum.
Keeping the specter of “scope creep” at bay requires two things:
Empowered Product Managers and Product Owners
Adopting a Minimum Viable Product (MVP) approach
to defining, developing, and fielding software systems
Formalize Product Management/Ownership
The concept of managing software systems as products is a foreign
concept for government program and project managers. The U.S. Federal Government treats software
systems development as a management activity for project managers to lead while
Agile takes a product management
approach to software development.
I detail the difference between project management and product management in another blog article. The main takeaway is that project management focuses on managing people, schedules, and activities while product management focuses on managing the product and its creation.
In the U.S. Federal Government’s acquisition model, program management offices (PMOs) manage contracts rather than software products/solutions. Requirements definition and solution approaches are left largely for vendors/contractors to figure out from initial sets of requirements developed by a different set of contractors. Developing solutions through active and ongoing engagement between the PMO, other government stakeholders, and vendors goes against how most federal acquisitions and contracting organizations are structured.
In Scrum, Product Owners are ultimately responsible for defining the solutions Scrum Teams develop. The Product Owner serves as the “Voice of the Customer”, synthesizing the various needs, wants, and perspectives of product stakeholders (both mission and technical) and customers into a coherent and cohesive product vision. Development teams depend on the Product Owner for direction and guidance concerning mission needs so they can define and build valuable software functionality.
This work of defining solutions cannot be outsourced wholesale to vendors in an Agile effort. Ascertaining mission needs and determining how solutions will address them are inherently governmental activities. PMOs must formalize the Product Owner role as part of how they do business. This is a move away from outsourcing the lead systems integrator (LSI) role to vendors and towards assuming a government-as-integrator role. Under this model, government collaborates with vendors as part of the team as opposed to assuming a distant customer stance.
Product Owners need to be government employees empowered to make decisions regarding solution scope and mission-facing functionality and be accountable for solution alignment with mission needs and requirements. Product ownership is a full-time job, not an extra duty for project managers. Government personnel who assume product management/owner positions must receive training, coaching, and support.
Adopt an MVP Approach
The only way to know if a solution is valuable is to put it
in the hands of customers and end users.
The key to doing so agilely is by releasing increments of valuable
functionality (something people can use to get real work done) iteratively
while ensuring the entire system delivers real mission value as it evolves. One way to accomplish this is to start with an
MVP.
An MVP is a hypothesis of the minimum functionality required
to provide mission value. The first MVP
is an initial version of the solution.
It is “viable” meaning that it is not a crude prototype but is instead a
stable, releasable capability. MVPs go
through a cyclical process of definition, development, release, usage
monitoring, and adjudication.
The MVP Cycle
MVP adjudication is a process step where we decide whether to add, modify, or remove functionality based on lessons learned from monitoring usage and performance data and from customer/end-user feedback. We may find that the current solution approach is not viable or will not satisfy requirements and decide to change the approach or abandon the MVP altogether; also referred to as pivoting away from the current solution path. Each iteration through the MVP cycle results in a new version of the MVP that delivers additional value. The MVP eventually matures into a solution that maximizes value.
The MVP cycle is an empirical process model that supports adaptive planning. The combination of empowered product ownership with an MVP-based development approach allows projects to control scope, while keeping within budget and schedule constraints and without engaging in heavyweight, agility-stifling, predictive planning.
Avoid EVM, Use MVPs Instead
Earned Value Management (EVM) is used to determine whether a project is on target to finish (i.e., deliver all planned functionality/scope), within a predetermined schedule and budget. The logic being that the sooner negative cost and schedule variances are discovered, the greater the likelihood the project can be managed back to plan. However, Agile is an empirical practice in which we monitor progress, make decisions, and take action based on what teams have released throughout the project. EVM is a definitive method in which project management predicts progress and works to prevent deviations from established plans. This fundamental lack of philosophical alignment between Agile and EVM prompts the question whether employing them together is reasonable and worthwhile.
An MVP-based solution development approach can help. MVPs break up the scope of large system implementations into smaller iterations. This allows programs to stay below mandatory EVM cost thresholds while lowering risk and providing the choice of stopping further development when mission needs are satisfied or when it is otherwise deemed necessary (e.g., bad contractor performance).
Focus on Shortening Program Lead and Cycle Times
Many organizational leaders think of Agile as a way to speed
up software development, and nothing more.
They obsess over adopting Scrum practices, DevOps pipelines, and Agile
tracking tools because they think in terms of increasing development team efficiency
and productivity rather than on continually improving program lead-time and
cycle time.
Lead Time and Cycle Time
Lead time is the time from when a customer orders a product to
when they receive it. Cycle time is the
time between gaining authorization to produce an order and completion of a deliverable
product. We replace the word “product”
with functionality, feature, capability, component, etc. when speaking about
software development.
Focusing on Agile and DevOps practices and tools affects cycle time. Developers are able to crank out more code faster, but what happens before developers start coding a feature and after the feature is ready for deployment? How big a percentage of cycle time is tied up in user acceptance testing, security checks, approvals, and integration activities (things out of the control of software teams)? How much time do these activities add to cycle time and lead time?
In a true DevOps environment, the amount of time actually spent writing, building, and testing code is a small percentage of lead time. In government programs, lead times dwarf cycle times and time-consuming project or program-specific processes lengthen cycle times. Often, organizations narrowly focus on improving the shortest time span within program lead and cycle times while ignoring huge time sinks outside of the work performed by developers.
The actions organizations need to take to lower lead and cycle times are organization-specific. However, one recommendation applies to any organization sponsoring Agile software development projects: They should identify and manage dependencies between software teams and organizational, vendor, and customer stakeholders from day one.
In Scrum, the Product Owner works to integrate stakeholders
in ongoing requirements and dependencies management. It may be advantageous to include stakeholder
representatives in Scrum Teams if the development teams need their input on an
ongoing basis to develop valuable and compliant functionality.
Conclusion
Getting the most agility out of Agilish projects begins understanding the rules of the chosen Agile approach and the statutory, policy, programmatic, procedural, and technological constraints within which the project must operate. Based on that understanding, some mix of tailoring the Agile approach and changing existing organizational processes is in order.
There is no “cookbook” on how to do this. Different organizations and projects will require different approaches and mistakes will be made along the way.
The important thing is to treat the shift towards Agile in an agile way. In other words, whenever possible, work in ways that align with the chosen Agile approach first. Only modify the Agile approach when laws, regulations, and policies absolutely require it. Work to become proficient in the Agile approach before attempting to change it to better suit existing ways of working.
This is guaranteed to bring stress and discomfort in the short term as people grapple with how they will accomplish their work under the new paradigm. However, as long as we treat changes as experiments from which to learn and improve and we implement them in an iterative and incremental manner, we will mitigate negative effects while progressively moving in the direction of greater agility, both from a technological and organizational perspective.
You are likely reading this because you are looking for a way to make Agile work within the byzantine world of government/public sector Information Technology (IT). My perspective comes from more than a decade of working with the U.S. Federal Government implementing software systems using Agile. I have spent a good portion of that time working in “hybrid-Agile”, “Scrumfall”, “Agilefall”, or “Agilish” projects. My advice: Do your best to avoid Agilish projects.
Reasons to Avoid Agilish Projects
Look, I get it. You
are likely getting conflicting direction from your government agency or
client. They want Agile’s speed and
flexibility with traditional project
management or “Waterfall” project controls.
They want end users to have greater say in shaping solution features
during development, but award firm-fixed-price contracts and require adherence
to inflexible program baselines. Even
when agencies use “Agile-friendly” contracting rules, contract language and
oversight requirements often impose Waterfall processes and reporting
requirements.
The problem is that you can’t have your cake and it too. There is no free lunch. <Insert another hackneyed phrase here> In trying to be both Agile and Waterfall, most Agilish government projects toss agility aside to accommodate established project management processes. I now discuss concrete reasons why Agilish projects are a bad idea.
Agilish isn’t a Real Thing
Hybrid Agile or Agilish is not a recognized software development approach. It is an project management approach to Agile without roots in proven Agile or software engineering practices. There is no standard framework (like Scrum) or body of knowledge (like SAFe or PMBOK) for Agilish implementations. Without standards or best practices, you’ll be making up your own Agilish implementation as you go. The same goes for contract firms that claim expertise in hybrid-Agile.
Predictive vs. Adaptive Planning
In traditional project management, the bulk of project planning happens before and immediately after the start of a project. This is a predictive planning approach. Predictive planning assumes the next project will be similar to previous projects. Thus, it is possible to estimate (predict) the amount of work (scope), necessary resources, timeframes (schedule), and cost (budget) of the next project based on historical data and experience. This assumption is fine for routine and relatively simple projects but breaks down for more complex, technically challenging, or innovative projects.
Agile planning is adaptive planning. In Agile, planning and management of risks and opportunities occur throughout the entire effort. Decisions are based on lessons learned and insights gained during development. This allows Agile teams to, “Welcome changing requirements, even late in development.”
The Worst of Both Worlds
Mixing Waterfall with Agile yields the worst of both worlds. You introduce predictive planning and project controls (e.g., Earned Value Management (EVM)) that sap the Agility out of Agile while lacking detailed program baseline data necessary to measure project progress and apply project controls a la Waterfall.
When Waterfall and Agile Mix
Agilish from the Start
In government institutions, the shift away from traditional project management to Agile is rarely, if ever, a bottom up initiative. Most likely, your agency or government client decreed Agile as its preferred or official software “project management” approach. Such pronouncements usually mark the beginning of Agilish projects.
Agile, and its most popular implementation, Scrum, are not “project management” approaches at all. Agile is an umbrella term covering multiple approaches (e.g., Scrum, XP, Kanban, Crystal) to building and delivering complex technical systems. These approaches share the tenets of the Agile Manifesto and its foundational 12 Principles of Agile, which I paraphrase and distill below:
Teams develop and deliver system capabilities
iteratively and incrementally within short timeframes
Empowered teams manage their own work and work
at a sustainable pace
The measure of progress is delivery of valuable
capabilities rather than alignment to plans
Direct and ongoing collaboration between and
among technical, organizational, and customer stakeholders largely replaces
formal documentation
Agile is a vision for a way of working, not a way of
managing work or workers. Scrum is a
lightweight framework of roles, rules, and best practices that embody the
tenets of the Agile Manifesto and the principles of Agile. Characterizing Agile or Scrum, or any other
flavor of Agile, as a “project management methodology” virtually guarantees
Agile adoption failure.
Software Development Has Changed
Most enterprise software solutions are complex systems that change and evolve for as long as they are operational. Agile and DevOps enable this ongoing evolution by:
Decreasing the time it takes to develop, test, and deploy new software capabilities
Increasing the frequency of new software capability deployments
Automating Operations and Maintenance (O&M) activities
Agile and DevOps allow organizations to move away from deploying
large software releases periodically or infrequently towards continuous flows
of software feature releases. A strong
DevOps culture fosters:
Close collaboration between developers and
systems operations personnel
Automation of system deployment, monitoring,
alerting, and troubleshooting activities
Agile does away with discrete Waterfall phases for planning,
analysis, design, testing, and deployment followed by a long O&M phase. All of these activities happen in Agile, but
occur continually and in rapid cycles, thanks to DevOps. Information and insights gained during these
cycles inform how solutions evolve and how teams improve technical quality and team
processes.
Agile and DevOps open the door to a different way of
working. DevOps enables software
development teams to deliver increments of valuable functionality sustainably
and when needed rather than on a set schedule.
As the speed and frequency of releases increase, scheduled project start
and end dates lose their significance.
We move into what some call a “Software Development as a
Service (SDaaS)” model. Instead of
standing up new projects, agencies augment available software development teams
or form new ones. The additional
software development capacity adds to the existing software development flows. Agencies have the choice of adding technical
contributors as agency hires or contractors.
By treating software development as a service capability, organizations
are able to ramp software development capacity up or down depending on mission
needs and budget constraints.
Conclusion
Acquisition of software systems by the U.S. Federal Government is transitioning from a traditional project management approach to Agile. Over the last five years, the Federal government has enacted significant statutory and policy changes to align acquisitions and contracting processes with Agile and DevOps. Unfortunately, this transition will take time due to the complexity of Federal acquisitions and contracting and the resulting decades-old predictive planning culture.
In the part two of this series, I’ll talk about the reasons why Federal software systems projects become Agilish and the resulting problems. Part three will cover ways to make Agilish projects more Agile.
Leveraging Impact Maps, User Story Maps, and Product Roadmaps to Align Organizational and IT Product Strategy using Scrum
This is the third and final part of a three-part blog series about aligning IT solutions/capabilities to organizational needs via an Agile-Scrum product management approach. You’ll find part one here and part two here.
In this article, I walk through how a Scrum Product Owner (PO), in collaboration with the rest of the Scrum Team and others, might bridge the “Product Management Vacuum” discussed in part II by leveraging impact maps, User Story maps, and product roadmaps for Product Backlog refinement and release planning.
Table of Contents
Part II Recap
In part II, I explained how the PO, as part of the Scrum Team, serves as the linchpin connecting the Scrum Team to the larger organizational product management structure. The PO is responsible for fostering and maintaining ongoing collaboration between and among the Scrum Team(s), project/solution sponsors and stakeholders, customers, and end users to:
Define and maximize IT solution value in terms of expected and realized business/mission value
Define a product vision and strategy that aligns with organizational vision and strategy
Align the work performed by development teams to product vision and strategy
This product management function bridges what Ralph Jocham and Don McGreal call the “Product Management Vacuum.” In the absence of a true product strategy, many organizations fill the vacuum with traditional project management activities that focus on managing tasks and people, rather than on defining the product/solution and improving development processes. This typically leads to wasted effort borne out of disconnects between the Scrum Team, the sponsor organization, customers, and end users.
Finally, I introduced Jocham’s and McGreal’s “Three Vs” construct. The “Three Vs” – Vision, Value, and Validation – sum up the product definition/management activities POs lead as part of their role. The “Three Vs” are mutually dependent and reinforcing:
Vision drives the creation of value (features/functionality)
Value created enables validation of business assumptions behind product development choices
Validation informs changes to the product vision
The Official Scrum Artifacts
I am taking the time to clarify that most of the artifacts I discuss in this article are not official Scrum artifacts. The Scrum framework includes three official artifacts: the Product Backlog, the Sprint Backlog, and the Increment.
…is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The Product Backlog is the single source of requirements for a product/solution
Only the features and functionality compiled and ordered in the Product Backlog make it into the product
Helps the PO manage development scope
The PO owns the Product Backlog
Tracks product requirements evolution as the product and its environment change towards providing greater value
…the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog makes visible all the work the Development Team plans to do during the Sprint
The highest ordered Product Backlog items become Sprint Backlog items
Sprint Backlog items have enough detail for the Development Team to understand what needs to be done
The Development Teams owns the Sprint Backlog
Only the Development Team can change its Sprint Backlog during a Sprint
The Development Team tracks progress and changes in work scope through the Sprint Backlog
…the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
The increment is not just what the Development Team develops during the current Sprint. It includes whatever system/solution functionality the team developed in previous sprints
Every new Increment must be “Done” at the end of the Sprint
A “Done” increment is ready for release and capable of providing usable and valuable functionality regardless of whether the PO decides to release it
Product Backlog Refinement
Product Backlog refinement is the management of product requirements by the Scrum Team. The PO leads Product Backlog refinement in collaboration with the rest of the Scrum Team (i.e., the Development Team and Scrum Master) and with input from product/project sponsors, stakeholders, customers, and end users. During Product Backlog refinement:
As the product evolves, higher ordered Product Backlog items become more detailed and the estimates become more precise. With help from the PO, the Development Team defines and decomposes the highest ordered items they plan to work during the next iteration/Sprint into User Stories. The Development Team manages those stories in the Sprint Backlog.
Product Backlog refinement is an ongoing process. The Scrum Team decides how and when to refine
the Product Backlog. However, the Scrum
Guide recommends the Scrum Team expend no more than 10% of its “capacity”
(i.e., the sum of productive hours across the team) on Product Backlog
refinement. Product Backlog refinement is
not restricted to specific timeframes or meetings. The PO can make changes to the backlog at any
time or have others do so at his/her discretion.
A Product Management Scenario Example
In part I of this series, I discussed organizational and product visions and strategies generically. To help visualize how all the parts fit together, I walk through a product definition and management scenario.
Over the last year, an online retailer has experienced a significant loss of market share to competitors. The company investigated reasons for the drop in returning customers and new registrations. The findings boiled down to customer dissatisfaction with business service functions across the value chain that negatively impacted the company’s reputation. While the company enjoyed an early market lead for years, competitors were quickly closing the gap with more innovative customer-centric service options and better delivery performance. The most significant problems found were:
Delivery problems
Customers receiving their orders late at a quarterly rate higher than industry average
Customer orders lost at a quarterly rate higher than industry average
Customers receiving the wrong orders at a quarterly rate higher than industry average
Customer service issues
Customer complaints about being bounced from one customer representative to another with a lack of continuity between representatives
Customer complaints about needing faster and more accessible help with “non-standard” issues requiring additional attention
Customer wish for an online customer service feedback option integrated with their ordering experience
Falling behind in offering new payment service options (Paypal, Google Pay, etc.)
Management shifted company strategy from a narrow focus on delivering
an “outstanding” website experience to improving the entire buying experience,
from online shopping to product delivery.
They revamped the company’s vision to match this new value stream-based
approach to customer satisfaction and updated their business strategy to
support it.
Company leadership recognized that a lack of customer focus caused the company to fall behind competitors and a subsequent decline in customer satisfaction. To address this, the company changed how it defines its services by instituting a product management approach. The company started looking at its website as a collection of online service offerings. Company strategy needed to be tightly coupled to customer needs and demands, changing as the market changes.
The table below breaks out the flow down of strategic vision and business strategy to tactical product vision and strategy I explained in part I of this series. The area highlighted in yellow is the “Product Management Vacuum” filled by organizational product management and POs in collaboration with the Scrum Team and with input from project/solution sponsors, stakeholders, customers, and end users. I focus on the strategic goal to increase customer retention and acquisition through better customer service down to the tactical goal of improving the company’s Customer Service System. Text of that tactical goal and its decomposed elements is colored red.
Table 1: Strategic Strategy to Product Strategy Decomposition
Defining Product Features
Armed with product goals, the PO works with the Scrum Team and others to define features they believe will help achieve them based on their current understanding of the business and market context. The Scrum Team continually refines that understanding as the Scrum Team releases features to users. The ultimate validation of the business assumptions behind new features is end-user validation. New insights shape future features/capabilities and business/mission strategic and tactical strategies.
Figure 1: Ongoing Organizational and Product Strategy Validation
Impact Mapping
Impact mapping is a strategic planning technique Scrum Teams
can leverage to develop Product Backlog items such as Epics and User Stories as
extensions to a defined product strategy. Impact maps are a great tool for
visualizing alignment from product vision to coarse-grained product backlog
items that Scrum Teams can order and further decompose and refine over time.
The diagram below depicts the use of an impact map to decompose the product vision and product objectives for the Customer Service System. One or more coarse-grained Product Backlog items support each product objective. These backlog items will collectively form the initial version of system requirements. Over the course of Product Backlog refinement and Sprint PlanningA time-boxed meeting where the Scrum Team plans the work to be done during the Sprint., the Scrum Team refines these items into User Stories. Each backlog item includes of three elements:
Actor – The role for whom the backlog item is for. The beneficiary of new feature functionality
Impact – The desired outcome from using the feature
functionality
Deliverable – The new feature functionality that will
help the actor achieve the desired impact
We avoid creating compound requirements. In other words, each backlog item is specific to one role, one deliverable, and one impact. These are high-level requirements, so the Scrum Team will identify, through their decomposition, different flavors of the same type of actor (e.g., administrator vs. regular user), related impacts for different flavors of actor, and related deliverables/features. It is important to remember that these are system/solution-level items. Too much specification now is counter-productive.
Figure 2: Impact Map
Product Backlog
Product Backlog Recap
After defining a set of course-grained requirements, we create the initial version of the Product Backlog. The Scrum Team writes requirements in the form of Epics and User Stories. User Stories are backlog items the Development Team estimates will take no more than one Sprint to complete and make ready for release, while Epics are estimated to take more than one Sprint. The Scrum Team decomposes Epics into User Stories as part of Product Backlog refinement.
At this point, we do not know how long it will take to complete each backlog item, so we do not know which items are Epics vs. User Stories. It is likely that these coarse-grained items will be Epics but I call them User Stories and group them under “themes.” The concept of themes is not part of the Scrum framework but they can come in handy when structuring the Product Backlog. Scrum does recommend adding backlog attributes to group items when multiple Scrum Teams are working from the same backlog.
The Product Backlog table below maps each backlog item to the desired impacts and product objectives listed in in the impact map. The product objectives become the value measures by which we measure whether each item’s feature delivers the expected business impact/outcome. I highlighted the Actor and Deliverable elements in each User Story.
Table 2: Initial Product Backlog
Based on the coarse-grained User Stories listed in the table above, the Scrum Team knows enough about what it plans to build to provide the Customer Service System’s tactical plan.
Table 3: Tactical Goal Decomposition with Tactical Plans
User Story Sizing and Product Backlog Ordering
I will not go into detail about how to size and order Product Backlog items in this article. However, I will highlight some key points that support the topics covered in this article:
The Scrum Guide refers to estimates rather than sizes. However, the most popular estimation techniques in Scrum leverage the concept of “relative sizing.” Instead of attempting to estimate how long it will take to complete a User Story, Scrum Teams use techniques like Planning Poker to estimate the story’s “size” relative to the other Product Backlog items. Relative sizing is faster to do, more intuitive, and becomes increasingly more accurate as the Scrum Team “matures” than estimating in hours.
As part of the Scrum Team, the Development Team is solely responsible for all estimates. The PO provides the business/mission context the Development Team needs to estimate the relative size of each Product Backlog item.
Typically, Scrum Teams estimate User Story sizes in “story points”, with “larger” stories earning higher point estimates. Often, the point scale used is the Fibonacci Series or a modified version of it. Story points are heuristically determined, numerical representations of User Story complexity, risk, uncertainty, and level of effort combined.
By tracking the number of User Story points the Scrum Team completes across multiple Sprints (at least three Sprints), the team determines its “velocity.” Scrum Team velocity is a heuristic measure of a Scrum Team’s throughput (not productivity). It is the rate at which a team delivers fully completed, tested, and accepted User Stories during a Sprint.
Scrum replaced Product Backlog “prioritization” with “ordering.” Ordering better connotes the concept of ongoing backlog refinement. Rather than periodically prioritizing backlog items according to vague business value categorizations, like High, Medium, and Low, and awarding multiple items the same priority, the Scrum Team continually orders backlog items based on their business value, risk, cost/size, and dependencies.
As User Stories rise in order, the Scrum Team fleshes out story details, provides more precise story point estimates, and decomposes larger stories into smaller stories the team can complete during a Sprint.
User Story Mapping
What are User Story Maps?
A Product Backlog is essentially an ordered queue. As the number of User Stories grows, it
becomes increasingly difficult see how all of the stories come together into a
system/solution. This is especially true
for solutions that involve workflows. A
list of ordered features, written as User Stories, does not communicate how
those features work together and what dependencies exist between them.
Scrum Teams can use User Story maps to organize an ordered Product Backlog across solution workflow steps, Sprints, and releases. Scrum Teams may use User Story maps in tandem with Product Backlogs to help identify dependencies as part of backlog refinement. It is a valuable tool to help plan releases as well.
Below is a User Story map example. The map is a simplified workflow for coarse-grained User Stories #4 and #5 in the initial Product Backlog I discussed earlier in this article. The User Stories read:
4. As a customer, I want the choice to provide feedback about the customer service I received so that I can communicate whether my issue was resolved to my satisfaction and why.
5. As a Customer Service Representative, I want access to customer feedback about issues I handle so that I learn how best to improve my performance.
The deliverable for User Story #4, listed in the example impact map, is a user feedback form. However, as described in User Story #5, there is much more to the form then just a webpage to enter data. The Scrum Team needs to develop a workflow that links multiple roles across the organization. User Story #5 is likely an Epic in need of decomposition while User Story #4 is likely a User Story the Development Team can finish in one Sprint. As Product Backlog refinement occurs, the scope of individual stories and of the entire workflow likely changes.
In this workflow, the Customer Service Coordinator reviews
incoming feedback submittals, categorizes them, and assigns them to the
appropriate part of the organization for resolution/acknowledgement. Should the initial assignment be inappropriate
or fail to yield a satisfactory outcome, the Customer Service Coordinator works
across the organization to identify the right people to address the
feedback. Otherwise, the customer
receives a response.
Below is a sample User Story map for this workflow.
Table 4: User Story Map Example
Let us walk through the User Story map’s elements:
Table 5: User Story Map Element Descriptions
The yellow cells in the User Story map example represent individual User Stories decomposed from the Epic directly above them in the “Walking Skeleton.” This decomposition is not one person’s idea of how the Epic should be broken down, not even the PO’s. It is instead the result of ongoing collaboration within the Scrum Team, informed by project sponsors and stakeholders, customers, and end users, and synthesized into a coherent product vision and strategy by the PO.
Development of a User Story map is an iterative process. As the solution takes shape iteratively and incrementally, more users, User Stories, business activities, and business tasks emerge, requiring changes to the User Story map and the Product Backlog. Fundamental changes in approach, predicated by insights learned during product validation, with actual customers and end users, may require changes to the product vision and strategy as well.
Product Roadmap
A product roadmap is a planning tool used to visualize when Scrum Teams estimate they will complete coarse-grained capabilities/Epics and in what order, over a given time horizon. A product roadmap facilitates planning, not just for the Scrum Team, but also for project stakeholders outside the Scrum Team. Common uses for product roadmaps include:
Communicating status and longer-term plans to
organizational decision makers
Identifying business/mission dependencies across
planned releases
Informs longer term business/mission planning
(e.g., funding, contracting, agreements with external partners)
A product roadmap is
not a schedule. It is a snapshot of
current planning, not a set of fixed milestone delivery dates. Short-term release timelines (no more than
three Sprints ahead) are based on User Story sizing and ordering (done as part
of Product Backlog refinement) as well as demonstrated Scrum Team
velocity. The PO bases longer-term
release timelines on the rank order of lower-ordered Product Backlog items and
current knowledge of dependencies between those items.
Like everything else in Agile and Scrum, product roadmaps
are always subject to change. As the
solution emerges and new learning happens, plans change. Agile planning is adaptive planning. Rather than creating detailed plans that span
months or years, Scrum Teams wait until “the last responsible moment” to plan only
the highest-ordered Product Backlog items in detail.
The recommended time horizon for Scrum Team planning is no
more than the next Sprint and two Sprints beyond that. Based on the recommended two to four-week
Sprint length, that is no more than 12 weeks.
The amount of implementation detail behind a User Story increases the
closer that story comes to being implemented by the Scrum Team. User Stories planned for the next Sprint are
much more detailed, and their estimates are better informed, than lower ordered
User Stories tentatively scheduled for later Sprints. Therefore, plans to implement solution
functionality beyond the next three Sprints are highly imprecise and likely to
change.
The sample Product Roadmap below maps the product strategy components I discuss throughout this article into a quarterly based plan for the year.
Table 6: Product Roadmap
Release Strategy
Depending on the size of the sponsor organization/company,
the PO either contributes to an organizationally agreed-upon release strategy
or collaborates with the Scrum Team, project sponsors and stakeholders,
customers, and end users in developing one.
A product release strategy dictates:
Release Frequency – How often Scrum Team(s) release functionality: the more frequently, the better. In Waterfall projects, there may only be only one a major release at the end of development. Release frequency for Agile/Scrum Teams ranges from releasing once at the end of each Sprint, to releasing multiple times throughout each Sprint, to achieving a steady flow of “done” functionality released on “demand” (Releasing functionality when customers/end users are ready to accept it)
Validation Frequency – How often customers and end users validate newly released functionality. Obviously, the more often Scrum Teams release functionality, the more opportunities for validation exist
In our company example, the company’s release strategy is to release at the end of every four-week Sprint. Scrum Teams monitor usage and performance metrics for the capabilities they release and the organization monitors customer feedback.
Table 7: Tactical Goal Decomposition with Release Strategy
Release Planning
The product roadmap provides a high-level, “broad strokes”
view of how planned releases fit together over an extended period of time. The Scrum Team plans releases at a greater
level of detail and across much shorter timeframes (no more than three
Sprints). A PO develops a release plan,
which aligns with the operative release strategy, in collaboration with the
rest of the Scrum Team, project sponsors and stakeholders, customers, and end
users. A release plan takes into account
the following considerations:
The Scrum Team’s capacity to develop “done”
capability at a sustainable pace
Technical and business/mission dependencies on
or arising from planned functionality
The ability and willingness of customers and end
users to “absorb” or accept planned changes
Alignment with business/mission strategy and
product strategy
Just like a product roadmap, the release plan is subject to change. Certainty over what a Development Team will develop and release over the next three Sprints is greatest for the next Sprint and becomes progressively less certain for the next two. However, since the release plan’s time horizon is so short and immediate, the frequency and magnitude of the changes should be significantly less than for a product roadmap.
Below is an example of a release plan for the Customer Feedback Workflow capability based on the User Story map discussed earlier:
Table 8: Release Plan
Conclusion
Scrum is a framework and as such avoids over-prescribing practices and artifacts. The expectation is that practitioners will adhere to its rules and tailor existing processes to align with the framework, not the other way around. The concepts and tools presented in this series are meant to be used as enablers for aligning organizational vision and business strategy with product vision and strategy using Scrum.
Scrum has an inherent product management bias that is a definite departure from the traditional project management mentality that has reigned over organizational IT for decades. A product management approach to organizational IT shifts project-centric, internally-focused sponsor organizations towards putting the customer first and focusing on achieving outcomes, rather than executing plans.
