IN THIS CHAPTER
Creating your actionable product roadmap
Turning your project into actionable-size chunks
Managing your master to-do list
Following common practices to expand the backlog
William of Ockham, a fourteenth-century logician and Franciscan friar, was quoted as saying, “Entities should not be multiplied unnecessarily.” In simpler, modern-day terms, this statement is known as Occam’s Razor. (When you have two competing theories that make the same predictions, the simpler one is better.)
In other words, Keep It Simple, Smarty. You can apply this mantra again and again when managing your project with scrum. If something doesn’t feel right, it probably isn’t.
In this chapter, you see that keeping things simple applies to a technique that we use to enhance scrum projects — called the product roadmap — as well as to decompose your product’s features into the smallest requirements possible.
Throughout this book, we point out common practices that scrum trainers and coaches use successfully. Although they’re optional, we recommend that you give them a try. They might make your project transition and completion more successful.
The Product Roadmap: Stage 2
In the seven roadmap to value stages we outline in Chapter 1, you begin with the end in mind by creating your vision statement (a common agile practice that works well). The next step is creating a map to help you achieve that vision (see Figure 3-1).
Although neither the vision statement nor the product roadmap is a formal aspect of scrum, both elements are common within the agile industry.
Creating a product roadmap is a common-sense way to set off on the journey and align an entire group. If you were to go on a voyage with a crew and passengers, you’d want to know your destination and most likely route before you leave the safety of the harbor. The same holds true with almost any project. Following are the general steps in creating a roadmap:
- Decide where you want to go (develop the vision).
- Figure out how to get there (design the product roadmap).
- Socialize the vision (communicate the plan).
The product roadmap can change, but it gives you something tangible to start with, thereby increasing efficiency. By socializing the roadmap as an artifact of planning or replanning, you can make sure that influencers and stakeholders understand the direction and path. Adjustments to the plan are less costly, and a shared vision contributes to team unification.
Take the long view
The product roadmap is a holistic, high-level view of the features necessary to achieve the product goal that you outlined in your vision statement. Natural project affinities are established (“If we do this, we should logically do that”), and gaps in features are made readily visible (“Hey, where is …?”).
The product roadmap is the initial product backlog (your master to-do list), and as the likelihood of product backlog items being developed increases, items are increasingly broken down (progressive elaboration). The product backlog expands to include items that are
- Small (imminently developable; often referred to as user stories)
- Midsize (midrange developable; often referred to as epics)
- Conceptual (clear but lacking details; often referred to as features)
See the sidebar “Roadmap and backlog terminology” later in this chapter for more information about features, epics, and user stories.
The product roadmap isn’t fixed in stone and fully paved; it’s a living, dynamic artifact. We review and update these roadmaps at least twice a year, although this frequency varies depending on the individual project.
Although the vision statement is fully owned by the product owner, the development team needs to be part of the roadmap–building process. Members of the development team are the technological experts who will be doing the work, and they must provide technical constraints and effort estimates. If the development team hasn’t been chosen yet, include the functional managers after you create the initial product roadmap. These managers can help identify the skills that will be necessary and get the development team assembled as quickly as possible so that the team can provide high-level effort estimates.
When we begin working with a client, we sit down with the business stakeholders, the product owner, the development team, and the scrum master and create the vision statement and the product roadmap on Day 1. We finish on Day 1 so that the actual development begins on Day 2.
Use simple tools
When creating your product roadmap, use the simplest tools possible. We prefer a whiteboard and sticky notes. Each product feature fits onto a sticky note. This method is simplicity in true working form.
Human brains weren’t created in the digital age. Studies have proved that electronics have a dulling effect. In fact, it takes less brain-wave function to watch TV than it does to watch paint dry. Yet using a simple system like sticky notes is physically and mentally engaging, and using it fosters an environment of change and creativity.
We have helped many clients create a product roadmap by simply placing sticky notes with major requirements on a wall and talking through ideas and issues. For one large project (worth almost half a billion dollars), we put a roadmap together in less than three hours. We start with the highest priority items. As we talk through the vision, stickies are simple to move as the roadmap begins to take shape.
Create your product roadmap
You can use seven easy, common-sense steps to build your product roadmap. Perform these steps on Day 1 of your project; they should take no longer than a few hours. For smaller projects, you’ll get the job done over morning coffee. The product owner completes the steps with the rest of the project team (the entire scrum team and the business stakeholders).
Using sticky notes, several colors of flags, and a whiteboard, follow these steps to build your product roadmap:
-
Write down one product requirement per sticky note.
Think of as many product requirements as you can.
- If appropriate and synergistic, arrange some requirements in related categories or groups.
-
Prioritize the requirements on the roadmap.
At the macro level, the highest-priority items are on the left side, and the lowest-priority items are on the right side. At the micro level, the highest-priority requirements are at the top, and the lowest-priority items are at the bottom. The highest-priority items are top-left, and the lowest-priority items are bottom-right.
- Identify business dependencies (noted by colored flags on the sticky note).
- Have the development team identify technical dependencies (noted by flags of a different color).
- Have the development team provide order-of-magnitude estimates for the sticky notes.
- Adjust ordering based on dependencies and estimates as appropriate.
Note the items that prompt the most discussion or concern from the team; these items may be the riskiest or require further breakdown. For estimation methods that your development team can use, check out Chapter 4.
Set your time frame
The nature of your product determines the quantity and timing of your product releases. We suggest a minimum of once per quarter, but the pace of innovation is increasing product releases. We have clients who push to production every day. The most successful social media and Internet firms push twice a day or more.
Ideally, you want to release tested, approved product after every sprint or, better, several times during a sprint (continuous delivery). Occasionally when working with clients, we create high-level product releases (for framing the requirements, not for timeline commitment) so that we can see how those releases align with other product releases, budgetary cycles, holiday cycles, and so on.
Figure 3-2 shows an example of quarterly product releases (common with publicly traded companies). The first release reflects initial release planning and has a level of commitment assigned to it. Everything after that shows how outside influences may affect the project.
If your time frame is shorter or isn’t relevant to your project, consider what your project’s time frame is and break it into the initial logical groups, going no farther out than necessary (usually, no more than a year). Follow these steps:
- Create the initial groups’ worth of features, starting with the highest-priority requirements and moving down.
- Assume at each product release that you will deliver tested, approved, shippable results.
- Above each release, write its conceptual theme.
- Adjust as necessary.
The product roadmap and product backlog are excellent for scope control. In traditional project management models, every new idea has to be justified. With scrum, if an idea brings you closer to the project vision, add it to the list. The idea’s level of prioritization determines whether it gets completed. Sometimes, only the highest-priority items get done; at other times, every requirement gets done, depending on the budget and the organizational drag on the scrum team.
Breaking Down Requirements
It won’t take you long to notice that one product requirement can be broken into several pieces. Chances are that those pieces can be broken down further, and those pieces, we’re willing to bet, can be peeled apart too. In this section, we explain how to manage this decomposition process.
Prioritization of requirements
With the product roadmap, you begin with the largest pieces of your project. This roadmap truly provides an eagle’s-eye view and is based on what makes sense according to business value and/or risk elimination. These pieces (requirements) are prioritized by the product owner, who decides what is most important to get to that customer first and which requirements logically belong together.
As requirements are prioritized, they become part of the product backlog. In scrum, you work on the smallest set of highest-priority items necessary to generate value, not just anything scoped for the project, which is why scrum projects release functionality faster.
Take two things into consideration as you prioritize: business value and risk. Business value is easy. If a thing has high value, it has high priority. You want to take on the highest-risk requirements first, for four reasons:
- At the beginning, you have the simplest system to work with. You want to take on your highest-risk developments within the simplest system.
- You have the greatest amount of money at the beginning. If you’re going to take on something that involves high risk, you should do so with the greatest resources at your disposal.
- Because you have the greatest amount of money, you can fund the development team for the longest time. If you’re going to take on a high-risk item, do so with the benefit of the longest runway possible.
- If you’re going to fail, fail early and cheap. If a fundamental flaw exists, you want to know as early as possible. The highest-risk requirements are where the land mines are lurking.
Working with the highest-priority requirements to completion isn’t just convenient, but also saves money and is why scrum projects can come in at a 30–70 percent cost savings. If your project runs out of money 80 percent of the way through, you can say without a doubt that you have 80 percent of the highest-priority items completed, functioning, and accepted. The remaining 20 percent? If they were such a low priority, many times you can live without them anyway.
The product roadmap creates your first cut of dependencies. For example, you don’t need to worry about having functionality to submit application functionality until you have a website to house that functionality. Critical dependencies are revealed early and help the product owner prioritize the product backlog. Teams begin working on the highest-priority items on Day 2, not Day 120.
A requirement must earn the right of your investment. Only the highest-priority items deserve your effort to break them into digestible requirements. Everything else can wait. This way, you’re always working on only the most important things. Don’t waste your time trying to boil the ocean. Learning and adapting is valuable even while building requirements.
Levels of decomposition
In decomposing your requirements into smaller pieces, you want to capture as little detail as possible. In fact, we want you to become expert in doing the bare minimum, progressively elaborating requirements as the likelihood of bringing them into a sprint grows. Gone are the days of spending endless hours working on defining and refining requirements that never see the light of day. Figure 3-3 depicts the layers of requirement decomposition.
Seven steps of requirement building
Seven steps are involved in building the scope of each requirement. At the end of the seven steps, you know that each requirement works, can be integrated, and has been approved by the product owner. You’re tangibly building products to showcase to stakeholders from whom you can garner feedback. This feedback is then used to refine and create new requirements that make the product better reflect stakeholder needs, and the cycle is run again. You incrementally improve the product based on reality.
The seven steps for building each requirement are
- Requirement elaboration
- Design
- Development
- Comprehensive testing
- Integration
- Documentation
- Approval
Your Product Backlog
The product backlog is a true scrum artifact and the master to-do list for the entire project. All scrum projects have product backlogs, which are owned and maintained by the product owner.
The requirements from the product roadmap initially create the product backlog, and the highest-priority ones are broken into user stories on Day 1. (We describe how in “Product backlog refinement” later in this chapter.) Figure 3-4 depicts a sample product backlog.
Each item in the product backlog has the following elements:
-
Specific order number (priority slot in the product backlog)
Although product backlog items may be similar in priority, they can’t be worked on at the same time.
- Description
- Estimate of the effort required to complete
- ID number (optional)
- Status (optional)
- Value to the business or product
- Type of item (optional), which could be a requirement, overhead, maintenance, or improvement (see “The dynamic to-do list” later in this chapter)
Highest-priority requirements get broken into the smallest actionable requirements possible in the product backlog. A small requirement, however, isn’t automatically a high-priority item. Many small requirements have low priority and never see production.
Anyone can write a product feature or requirement. An idea or concern can be sparked by a business stakeholder, a member of the development team, the scrum master, the product owner, and even the company barista. Ideas are expected from everyone. Only the product owner has the power to accept or reject a requirement into the product backlog, based on whether it supports the vision for the product. The product owner is the full owner of this artifact. If accepted, they will then number, refine, prioritize, and order that new requirement.
The dynamic to-do list
The product backlog never goes away while the project is active. If you have a project, you have a product backlog, which is always changing. As larger requirements are broken into smaller requirements, the backlog changes. As client feedback is received, the backlog changes. As your competitors bring new offerings to market, the backlog changes.
The product owner not only prioritizes items in the product backlog but also orders them in a logical sequence. This way, the next sprint can be quickly and efficiently organized from these ordered items.
All changes made in the product backlog are made by the product owner. At any point, if anyone (product owner, developer, stakeholder) identifies a new requirement or design idea, it’s given to the product owner to be prioritized along with everything else.
In traditional project management frameworks, change is viewed as a reflection of poor planning. If something had to be changed, it was because someone messed up. In scrum, we see change as a sign of growth. As you discover your product more deeply, you will identify changes that need to be made. In scrum, if you’re not changing, you’re not learning, and that’s a problem. It’s a lack of change that is a sign of failure. Every day you need to learn something and that causes change. With scrum, change is no longer something you crawl under your desk and hide from. Change is good. Change is life. Change is scrum.
Product backlog refinement
Product backlog refinement is how the scrum team advances its understanding of the items in the product backlog and prepares them for upcoming sprints. Product backlog refinement is a continuous process of breaking down and preparing feedback and responses to change for future development. This process is owned by the product owner and performed with the help of development team members, who ask clarifying questions and provide estimates based on the best information available at that time. The scrum team as a whole spends up to 10 percent of its active sprint time in this process. The scrum master usually facilitates product backlog refinement activities to keep the group focused and on task.
The target outcomes of product backlog refinement are
- Clarity: All developers and the product owner reach a clear consensus on the scope of the product backlog items being discussed.
- Acceptance criteria: All requirements (backlog items) include sufficient acceptance criteria.
- Risks identified and mitigated to the best extent possible: Other known risks should be documented and accepted by the team as necessary.
- Sizing: Requirements are estimated and broken down sufficiently to be accomplished within a sprint.
Acceptance criteria is a term frequently used in scrum practices. It refers to a section on the back of the story card or in project software to communicate to everyone what “done” means for each story. It may include testing criteria and specific examples of how the feature is expected to function when the work is complete.
Backlog refinement should be a regular occurrence, but scrum doesn’t prescribe how formal or frequent refinement discussions should be; neither does it prescribe an agenda. Here are suggestions that have worked well for us and our clients:
-
Format: The product owner presents one requirement to the team at a time. For each requirement, team members ask questions, challenge assumptions, explore implementation strategies, and use a whiteboard for drawing and clarification until they have consensus on the details and scope of the requirement. Then the development team uses estimation poker or affinity estimating (see Chapter 4) to assign a relative estimation.
For a requirement that moves up in priority, the estimation indicates when the requirement is small enough to fit into a sprint.
- Time: Scrum teams on average spend about 10 percent of a sprint in refining the backlog in preparation for the next sprint.
- Frequency: Backlog refinement is a progressive activity. Requirements get refined gradually, just in time, with those closer to delivery being made ready for sprints. Teams may prefer conducting backlog refinement on one of these schedules:
-
Daily, at the end of each day
This schedule also acts as a demobilization exercise for development team members to transition into going home for the day.
- Daily, at some other agreed-on time
- Once per sprint during a regularly scheduled block of time
- Once per week during a regularly scheduled block of time
- Multiple times per week during a regularly scheduled block of time
- As needed, determined, and scheduled by the team in each sprint
- Activities: Backlog refinement activities may consist of the following types of activities:
- Entire team discussions, including whiteboarding, modeling, question-and-answer sessions, and design discussions
- Research of items identified during team discussions
- Interviews of subject-matter experts or stakeholders to gain insights for determining scope and suggested solutions to requirements
- Estimation poker or affinity estimation sessions
As the team discusses and refines the next-highest-priority requirement candidates, use as many of the following questions and guidelines as needed to guide the team through the refinement process. Not all these items apply to every team and/or requirement.
- Breaking down large requirements
- Does the user story satisfy the INVEST criteria (see the “INVEST” sidebar later in this chapter)?
- Can the requirement be completed within one sprint or part of one sprint?
- Is the user story a single action of value or a series of actions?
- Is the scope barely sufficient?
- Has the product owner added technical tasks or other technical details that should be left to the development team to determine?
- Has the scrum team’s definition of done (see Chapter 4) been considered before determining that the story is sufficiently broken down?
- Is more research required before the team can estimate?
- Clarifying and refining where needed
- Does the development team understand the business intent and/or value of the requirement?
- Have development team members tried paraphrasing the requirement to make sure that everyone is on the same page?
- Is the desired deliverable clear?
- Does an implementation approach make sense from both technical and business perspectives?
- Is the team considering all the work needed to fully complete and deliver the story?
- Does the team know the tasks that will be required?
- Will the team be able to deliver a fully done increment of the product at the end of this sprint?
- Ensuring adequate acceptance criteria
- If needed, have personas been identified (see “Product Backlog Common Practices” later in this chapter).
- Are the acceptance criteria complete and adequate?
- Have test-oriented development team members stated that the criteria are sufficient?
- Addressing potential issues and risks
- Can the story stand alone, or are there dependencies?
- What conflicts may arise during implementation?
- What technical debt might this requirement introduce?
- Assigning high-level estimates
- Has the scrum team decided on a consistent estimation method (see Chapter 4)?
- Has the team agreed on how to reach consensus?
- Have estimations revealed that any of the requirements are still too big?
If estimations bring up additional points that need clarification, use these guidelines to further refine them before reestimating.
You need to watch a few factors in this process:
- Only development team members estimate requirements because they’re the ones doing the work.
- The product owner provides immediate clarifications to developers’ questions by being actively involved in the refinement discussions.
- The frequency and duration of refinement activities will vary from team to team, from project to project, and even from sprint to sprint.
Other possible backlog items
When we coach clients in building their product backlog, we encourage them to identify a type of backlog item (refer to Figure 3-4 earlier in this chapter).
We use four types to clarify the nature of the item to be completed. All these items can be done (or not done) at the product owner’s discretion:
- Requirement: Basic business requirements make up the bulk of a product backlog. A requirement explains why a feature is being built and what needs to be done.
- Maintenance: Design improvements for the code, such as fundamentally rethinking a login class that can’t be tactically tweaked anymore. Maintenance items reduce the technical debt of the project.
- Improvements: Based on results from the sprint retrospective, what can be done differently in the process, such as expand automated testing skills.
- Overhead: Companies often have overhead items that they like to see, such as a requirement traceability matrix, and most companies don’t add the matrix into the equation. They assume that it’s free, but it costs time and money. We like to make that cost obvious.
Product Backlog Common Practices
Agile techniques are practiced by thousands of companies and organizations throughout the world. As a natural result, common agile practices abound. We incorporate some of these practices into our consulting business and discard others. We recommend that you do the same. No set of universal best practices exists.
User stories
User stories are used to gather customer requirements. User story is a common term for requirements small enough to be brought into a sprint and broken into tasks. User stories are one action of value that a user will achieve, such as “As a shopper, I want to be able to scan a product bar code with my phone so that I can compare and find the lowest price of the same product at multiple stores.”
Multiple user stories go into every sprint, and each are highest priority at that time. On average, you may have six to ten user stories per sprint. Therefore, at the end of each sprint, if the development team concentrates on completing one requirement at a time (a process called swarming, described in Chapter 6), you always have something to show for your work.
We use 3x5 index cards to write user stories. Even with these small cards, because we use a Card ⇒ Conversation ⇒ Confirmation model, we get rich requirement clarity before development starts. User stories aren’t the only way to describe what needs to be done, but we’ve found them to be incredibly effective. Figure 3-5 shows example index-card user stories.
Don’t use technical jargon in your user stories. You’re writing them with the user in mind. Keep them direct, customer-focused, and simple.
In the Card ⇒ Conversation ⇒ Confirmation model, the product owner uses the 3x5 card as a reminder of the requirement — a reminder that a conversation must take place to refine and clarify it. This model enables the immensely valuable activity of conversing with development team members and answering their questions, supported by an explicit description of what success looks like on the back of the card. Previously, we developed tomes of documents before having a development team as we tried to answer all the questions we thought that team might have — an endeavor in which we invariably failed.
Sometimes, it’s easiest to work with personas: fictional characters who are amalgams of the target qualities of your clients. A persona might be a 35-year-old single male, professionally employed, who lives in Portland, Oregon, and is looking for his future significant other. Use a persona to ensure that your project meets your target customer’s needs.
A user story description is simple yet focused, clearly describing the user, the action, and the benefit. On each card, enter the following lines:
-
An ID number that’s the same as in the product backlog and that’s assigned by the product owner when she accepts an item into the product backlog
Keep your product ID numbers simple. You don’t need to be able to track every item back to its more generic origin; you just need to give it a numerical name, like 123, not like 10.8.A.14. You minimize the amount of work you do by ridding your project of time-wasters so that you can focus on the important things.
- A shorthand title
- A description of the user
- What the user wants to accomplish
- The reason the user wants to accomplish the task
Critical to the user story is what’s written on the flip side of the card — the acceptance criteria. This is how you know that the user story has been successfully implemented. It’s phrased as “When I do this… this happens.
Figure 3-6 shows an example of a completed card.
Each user story is written in the first-person point of view (“When I do this, I get this”). First person puts the author in the shoes of the user or customer.
The person who writes the user story gives it to the product owner to share with the development team. Often, the stakeholder also participates in the conversation phase, sitting down with the product owner and development team to go over every card. This act of direct communication is vital to a thorough understanding of the tasks necessary to achieve the result desired. As a result, communication is clearer and mistakes are fewer, and project quality and delivery speed increase.
Further refinement
Development team effort determines whether a requirement needs to be broken down further to progress to the product roadmap, into the release plan, or into the sprint (see Chapter 5 for details). Especially at the beginning, as you find out how to apply user stories within your scrum framework, you may find that the ones you write are too big to fit into a sprint.
Although most user stories have multiple steps, some are bigger than practical and can (and should) be broken into more granular requirements. This process is part of the discovery process and part of the benefit of using user stories.
You may find additional requirements that need to be placed in the product backlog during the user-story elaboration discussion. Excellent! These discoveries help you gain deeper understanding of what the customer and/or user need.
