How you use “Agile” support tools could sabotage your agility
How an organization uses “Agile” requirements management and team collaboration tools like JIRA is an indicator of how well that organization aligns its management of software systems development with Agile software development. The least “Agile-mature” organizations attempt to manage Agile projects with traditional project management biases and expectations. Such organizations often use Agile requirements management and collaboration tools to track and report:
Traditional project management metrics
“To-do” lists of unprioritized and unsized items written like traditional requirements or developer work tasks
All the while, organizational leaders and management assume they are “Agile” because they are using “Agile” tools.
The Place of Tools in Agile
Before expounding on these two general misuses of Agile requirements management and collaboration tools, let’s go over what the Agile Manifesto for Software Development says about tools. Agile values, “Individuals and interactions over processes and tools.” While Agile teams institute processes and use tools to manage their work, they value direct interaction between individuals more. Under this construct, tools are enablers that facilitate communication between team members and project stakeholders. They are not substitutes for direct communication.
Agile prefers face-to-face communication over emails, phone calls, project tools, formal boards, documentation, etc. This way of communicating increases agility by avoiding the use of intermediary channels, documentation, and reporting structures that often slow and distort communication. It also prevents formalizing decisions too early, which unnecessarily narrows options and commits development teams to approaches that may prove wrong after having spent significant time, money, and resources implementing them.
However, not every interaction in and among Agile teams can be face-to-face. Agile development teams with members who work remotely, and enterprises staffed entirely with remote teams, are common. While Agile best practice is to collocate teams and team members, it is not always possible. For example, the project team may be too large to depend solely on direct communication between members.
Agile requirements artifacts are purposely lightweight. They work as reminders for future conversations that will flesh out details. However, even lightweight requirements become difficult to manage as they grow in number. Requirements management and team collaboration tools help document and track requirements, manage work, and report progress. They also help bridge distances and time zones between collaborators.
Project Metrics Tracking
The types of metrics relevant to traditional vs. Agile projects are different. Traditional project management is concerned with managing the constraints of the Iron Triangle: Cost / Budget, Schedule, Scope, and Quality.
Figure 1: The Iron Triangle
Fixing the former three constraints leaves quality as the only variable, opening the door to sacrificing quality to adhere to the other constraints. We can sum up the Iron Triangle with the adage, “I can get it to you cheap, fast, or good. Pick any two.” On the other hand, we manage Agile projects primarily by managing scope. We fix schedule and budget while treating project scope as variable and not sacrificing quality.
Traditional Project Metrics
Keeping the first three constraints of the Iron Triangle fixed throughout a project requires adherence to detailed project plans. Changes to those plans are highly frowned upon since even small changes can ripple across project plans in unexpected ways. Thus, traditional project managers focus on managing people and tasks to keep projects on track with plans. This leads to collecting metrics such as the ones shown in Table 1 below:
Table 1: Common Traditional Project Management Metrics
Agile Project Metrics
Agile projects hold schedule and budget fixed while treating scope as a variable. In essence, we have a span of time, a bucket of money, and the flexibility to build just enough of what is needed to satisfy customers. When schedule or budget run out, we can stop development or pony up more money to build more. We also have the flexibility to stop the project at any time should we decide that we delivered enough functionality or if the project is no longer viable. Cancelling a failing or unnecessary project after spending $10 million is much better than doing so after spending $100 million.
Since Agile teams are self-organizing, they manage their own work. They do not need management to allocate tasks, lead estimation activities, or coordinate between teams. Also, in Agile, “Working software is the primary measure of progress.” Therefore, metrics like percentage complete are unnecessary (and nonsensical) since we regularly evaluate complete and releasable business or mission functionality. In Agile, a feature is either done or it isn’t and teams do not take credit for work on incomplete features. What “complete” means to project teams and stakeholders makes up the “Definition of Done”.
“Agile metrics” help teams:
Manage current work
Plan future work
Communicate project status across teams and project stakeholders
Many Agile approaches / frameworks exist. In the Table 2 below, I provide Scrum metrics and reports as examples. I avoid discussing the details of tracking, reporting, and using these metrics and reports in this article. Instead, I present these examples to drive home the point that what we measure, track, and report in Agile projects is different from that of traditional project management because the two approaches are fundamentally different.
Table 2: Common Scrum Metrics and Reports
Quality Metrics
Measuring the quality of deliverables and acting on findings is crucial to all software development projects, Agile or not. There aren’t Agile-specific measures of quality. However, like traditional requirements, well-formed Agile requirements specify the outcomes and quality characteristics associated functionality must meet. In Scrum, for example, quality criteria inform user story acceptance criteria.
Tracking Traditional Project Management Metrics via “Agile” Tools
Many organizations configure and use tools like JIRA to collect and report traditional project management metrics. This practice demonstrates a fundamental misunderstanding of Agile and how it differs from traditional project management. It is also indicative of organizations that adopt the terminology and mechanics of an Agile approach or framework without embracing its principles. While tools can enable Agile practices, agility is not the result of using tools.
Using Product Backlogs as “To-Do” Lists
Tools like JIRA are primarily designed to support Scrum teams. As such, they organize work through product backlogs. A product backlog is a prioritized list of estimated or “sized” descriptions of business or mission capabilities needed by users or roles (human or automated) to accomplish specific outcomes. Scrum teams typically write these requirements as user stories:
Unfortunately, it is quite common to see user stories written as system components or deliverables or as developer tasks. Many teams also neglect to size and prioritize product backlog items until sprint planning (and sometimes not at all). Rather than managing a product backlog, such teams work from what is ostensibly a to-do list. Doing so takes away the ability of Scrum teams to manage current work, plan future work, and clearly communicate project status.
Conclusion
Requirements management and team collaboration tools like JIRA are useful for documenting and tracking requirements, managing work, and reporting progress. However, using such tools is not the same as being agile, especially when used to support traditional project management processes and reporting. Understanding the differences between Agile approaches and traditional project management is key to ensuring we avoid contorting Agile to support Waterfall processes and expectations.
This is the third and final video of a series that explains and compares the Work Breakdown Structure (WBS) and Scrum’s product backlog. In this video, Frank Velazquez compares and contrasts the two artifacts and how they support very different approaches to project scope management between traditional project management, or Waterfall, and Agile. This understanding is crucial for viewers implementing Agile in organizations steeped in traditional project management.
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:
Management of Product Backlog Items: The creation, retrieval/tracking, update, and deletion of items
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?
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.
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:
Business/Mission Value
Cost/Size
Time Criticality
Technical Dependencies
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:
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.
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
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.
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.
