Module 3 Creating the Product Roadmap€¦ · delivering on a release timeline. The roadmap is a...

© 2018 Rachel Alt-Simmons, Boston University, All Rights Reserved

Module 3 – Creating the Product Roadmap

Table of Contents

Study Guide ...................................................................................................................................2 Reading ................................................................................................................................................................. 2 Assignment ........................................................................................................................................................... 2

Module Overview ..........................................................................................................................2 Outline .................................................................................................................................................................. 2 Learning Outcomes ............................................................................................................................................... 2

Establishing the Product Backlog ....................................................................................................3 User Journey Mapping .......................................................................................................................................... 3 User Flow / Story Mapping ................................................................................................................................... 4 Concept Mapping ................................................................................................................................................. 5

Creating the Product Roadmap .......................................................................................................7 The Product Backlog ............................................................................................................................................. 7 Release Planning ................................................................................................................................................... 8 Backlog Grooming ................................................................................................................................................ 9

The Scrum Framework ................................................................................................................. 11 Scrum Roles & Responsibilities........................................................................................................................... 11 The Scrum Team ................................................................................................................................................. 11 Scrum Processes ................................................................................................................................................. 16

Summary ..................................................................................................................................... 21

References ................................................................................................................................... 23


Study Guide

Reading • Course module content • Rubin, Chapter 6, Product Backlog • Rubin, Chapter 2, Scrum Framework • Rubin, Chapter 4, Sprints

Assignment Team Assignment: Capability Mapping & Product Backlog

Module Overview

In this module, we start leveraging our user insights to formulate our product backlog: The functionality

that we want to deliver to our users. To ensure completeness of our user interactions, we can use a

number of different methods to understand how our users want to engage with the solution. Once we

understand the required functionality, we create our product roadmap, which outlines what we will be

delivering on a release timeline. The roadmap is a key communication document that the product owner

can share with stakeholders, and aligns the team to a common purpose and goal. With our initial

planning activities complete, we begin to prioritize and groom our product backlog for delivery work.

As the team starts the Scrum process, we’ll cover the Scrum team structure as well as processes and

activities within the Scrum framework. This includes some of the team planning aspects of sprint

execution, including the use of a sprint zero to get the team off to a successful start.

Outline

• Understanding user experience design methods that can be used to define interactions in your

solution

• Establishing a product backlog

• Creating a product roadmap and release plan

• Provide an introduction to Scrum roles and responsibilities

• Provide an outline of the Scrum framework

Learning Outcomes

The expected learning outcomes for this section of the course are:

• Understanding how to develop a product backlog through user experience methods

• Learning how to take the backlog and establish a product roadmap and release plan

• Develop practical knowledge around Scrum roles and processes


Establishing the Product Backlog

In our previous module, we developed personas that help us understand what motivates our users,

uncovering their wants/needs, their frustrations, and things that delight them. Now that we have a

better idea of who we’re developing for, we need to identify how those users will interact with our

solution to achieve their objectives and understand the context of those interactions. Customer

interactions are more complex today than ever, with a single experience taking place across a variety of

devices, channels, applications, products, and services. By mapping our users’ interactions, we can start

to build the backlog of capabilities for our solution. This process helps us ensure the completeness of

our solution designs. There are many different ways to capture user interactions: Let’s review a few of

the more popular methods.

User Journey Mapping

A user journey map (also a customer journey map) is a visual representation that illustrates your user’s

engagement touchpoints around interacting with a product, service, or a particular experience. The map

encompasses what happens around the interaction, and not just the interaction itself, providing context.

If our product is a mobile app, by evaluating what the user is doing before and after using our app, we

can identify additional areas for development or even new solution ideas.

Creating user journey maps are a logical next step after completing your user research study and

developing your personas. The map is typically very high-level and provides a frame of reference for

identifying solution boundaries. You’ll find a variety of user journey map formats out there. There’s no

right or wrong example. Find examples and use what makes sense for your project and your audience.

That said, there are a number of guardrails that you should be mindful of.

Don’t think of the journey map as a detailed process flow, but a simplified view of all of your customer

touchpoints. The goal isn’t to create something that illustrates every detail, but reflects reality in a

conceptual way. A user journey map is also not user interface design. Rather than focus on the design of

the system, the map encompasses the user’s behaviors, emotions, and reactions in the context of the

activity that you’re assessing. The map encompasses the user context that surrounds the activity that

you’re assessing.

If you have distinct persona groups with their own set of interactions, you may want a journey map for

each group. It provides a way to visualize the interactions that you captured during your user

experience research. The journey map provides us with a mechanism for visualizing our users’ pathways

and helps us determine what our opportunities are for developing our solution.

You want to understand and address this customer challenge by creating a customer journey map (after

conducting some ethnographic research, of course). Here are some areas that they would want to

evaluate in that journey:

Stages: What are the stages of the customer journey?


Actions: What is the customer doing at each stage? What actions are they taking to move themselves on

to the next stage? (Don’t list what your company or partners such as retailers are doing here. That will

come later when we look at touchpoints)

Motivations: Why is the customer motivated to keep going to the next stage? What emotions are they

feeling? Why do they care?

Questions: What are the uncertainties or other issues preventing the customer from moving to the next

stage?

Barriers: What structural, process, cost, implementation, or other barriers stand in the way of your

customer moving on to the next stage?

While we’ve outlined our journey in a sequential manner, your customer’s journey may not be so linear.

Your customer may jump back and forth from stage to stage, or skip certain stages altogether.

Listen to customer experience guru Jeneanne Rae talk about customer journey mapping at the

cosmetics store Sephora: https://youtu.be/-MC_jmtlrOQ

Here’s an intro on how to start mapping your customer journey: https://youtu.be/r8cPjTWbtSA

User Flow / Story Mapping

Journey maps provide a good way to conceptualize the context that your solution will be used in, but we

need to outline additional detail that is specific to our solution. User flow mapping is a way to step through

user interactions to ensure that the flow makes sense to the user, and to ensure that you haven’t missed any

important areas for development.

In a user flow example pulled from this week’s assignment, the larger boxes represent what your user wants

to do on the website. In the smaller boxes in the flow, document the steps that take place to complete that

action. Creating user flows helps us identify the different capabilities (or features) we need to enable in our

site design and some high-level dependencies. The smaller boxes start to form the backbone of our product

backlog. Remember that the backlog is a placeholder. As you start to prioritize the work, you decompose it to

a level that is executable within a sprint. The last feature "Rachel creates new design portfolio spotlight" may

need to be broken down into more discrete steps.

https://youtu.be/-MC_jmtlrOQ

https://youtu.be/r8cPjTWbtSA


Concept Mapping

Concept mapping (also known as mind mapping) is another important capability that you can use to

ensure the completeness of your designs and your content. The concept mapping process is simple –

using a mind mapping tool, you can define and associate concepts together. This is especially helpful

when you’re trying to determine the relationship between ideas and content.

In another example from this week’s assignment, we can use a mind map to associate content for

different areas of our site design. Basically, there’s no limit to how you can use concept maps – they’re

just a great way to organize disparate information into logical flows or groupings. In this example, the

association of content helps us to think about what backlog items we may need to incorporate to

address content.


Creating the Product Roadmap

As product managers identify customer and stakeholder needs using the methods outlined in the

previous section, they are often captured in the form of a product backlog. The backlog is a placeholder

for things we want to incorporate in the development of our solution. Once we’ve prioritized the items

in our backlog, we can lay them out on a development timeline called the product roadmap which

illustrates what functionality will be delivered within a pre-determined release schedule.

The product roadmap is a visual artifact used in the planning process that illustrates how the product

will evolve over time. This planning document helps cement the shared vision of the product across the

different stakeholder groups, including the product owner and the project team. Additionally, the

roadmap facilitates coordination between and across project streams by providing a high-level view of

the project, its features and target customers. The roadmap’s planning horizon should reflect a realistic

timeline (typically six to twelve months). The team orders functionality on the roadmap by importance

and sequence, and defines releases based on what the team believes it can deliver within a certain

timeframe. The longer-term roadmap and release plan is negotiable – as user needs and organizational

priorities change, we can reorganize, remove, and add new capabilities.

The Product Backlog

Once we’ve completed our user mapping activities, we can continue to decompose those activities into

an initial set of requirements called backlog items. The good news is that we don’t have to be exhaustive

in this collection process. One of the key benefits of using an agile methodology is that we can continue

to add new requirements as our customers react and respond to what we’re delivering to them.

But we have to have a place to start - agile teams don’t compile a large inventory of requirements up

front, but instead create placeholders for requirements that form the backbone of the product backlog.

Each product backlog item represents some component of business value. Initially, the backlog items

may be very large in scope with little detail associated with them, such as the interactions we captured

in our user journey, flow and concept maps. As backlog items become prioritized, the stakeholders,

product owner and development team refine and clarify the items into a collection of smaller backlog

items until they’re small enough to be completed in a sprint, a time-boxed increment of development

work.

Not all requirements are at the same level of detail at the same time: A strategy of progressive

refinement (or elaboration) is used to decompose large, lightly detailed requirements into smaller, more

detailed components as they are slotted for development work. At this point, product backlog items are

rewritten in the form of a user story.

In the words of Jeff Patton (2014), “There’s always more to build than you have people, time, or money

for. Always.” In fact, on large complex projects, you might have different teams establishing different

backlogs. So how do we start to coordinate, organize and prioritize our initial set of backlog items?


Your user personas are a critical input into this process. Jeff Patton puts it this way (2014) “Of all [the]

different users and the things they want to do, if we were to focus on thrilling just one of those users,

who would it be?” Answering that question can help you start to prioritize.

Release Planning

Once an initial set of backlog items has been identified and prioritized, the team can begin to coordinate

a release plan. A release plan provides a fixed date when a product can be officially released to the

customer or users of the solution. A typical release cycle may be every one, three or six months, and can

differ across applications. For example, applications that are classified as systems of engagement (like

Facebook) may release multiple times a day. A system of operation, like a general ledger system, may be

on a 6-month cycle.

Release planning is not a once-and-done activity, but takes place throughout the project. The initial

release plan is prepared following the product visioning process. If the product is new, the initial release

plans may not be complete or precise. The organization continues to learn as development work

progresses, and release plans are subsequently updated. The extended agile team (stakeholders and

developers) participates in the release planning process so that technical and business trade-offs can be

weighed.

Product backlog grooming also takes place during release planning. The grooming process includes the

creation, estimation and prioritization of product backlog items. Each release contains a well-defined set

of minimum releasable features (also known as minimum marketable features or MMFs). This is also

sometimes called a minimum viable product or MVP. Shore and Warden (2008, p.211) define an MMF as

“the smallest set of functionality that provides value to your market, whether that market is internal

users or external customers.”

There are two common scenarios in the release planning process. The first is that you have a fixed

deadline that you have to meet. In this case, your scope is negotiable because you have to hit the

deadline date. The second is that scope is fixed, and you have to identify the tradeoffs in delivering

certain functionality across multiple release dates. At this planning stage, your backlog items will have a

high-level estimate assigned to them, possibly no more granular than “small-medium-large-extra large.”

Using your story map, target MVP, and rough estimates, you can start to evaluate whether the work can

be accomplished within the desired timeframe. Another input is the team’s velocity. Velocity is a

measure of the team’s ability to complete work per unit of time.

Each release may encompass several sprints. Some organizations use a practice called continuous

deployment (or delivery) where features are released to customers as they are completed. However, for

software companies producing enterprise class software, the release schedule may be much more

formal. Release planning cadence depends on your organizational objectives and your customers’ needs.

The important thing is to focus on delivering something meaningful to your customers by the end of the

release.


Backlog Grooming

Grooming is the process of managing, organizing, and administrating the product backlog. There are

three principal activities in the grooming process: creating and refining, estimating, and prioritizing

product backlog items. Grooming is a constant activity throughout the project duration. While the

product owner retains primary responsibility (and is the decision-maker) for grooming, it is a

collaborative process. Backlogs are made up of functionality that have tangible value to the customer,

but may also include defects, technical improvements or knowledge-based work.

Go DEEP

Mike Cohn (2013) and Roman Pichler (2010) advocate a DEEP approach to managing the product

backlog. The DEEP acronym stands for: detailed appropriately, emergent, estimated, and prioritized.

Using the DEEP criteria can help determine if the backlog is structured appropriately.

Detailed Appropriately

High priority items contain more detail than low priority items. This ensures that too much data is

not collected upfront and the team is focused on the top items in the queue. As we highlighted in

the last lecture, the highest priority product backlog items should be small and detailed enough to

include in the next sprint. As the team reaches down into the queue, large backlog items (often still

“epics” at this point) are refined in a just-in-time manner. This is a careful balance: if the item is

refined too early, the team may be wasting time on something that won’t be implemented, and if

they refine too late, it may drag down a sprint.

Emergent

The product backlog is continually updated based on new information provided by internal and

external stakeholders. As a result, the product backlog emerges over time. The product owner takes

all of these inputs and uses it to rebalance and reprioritize items within the product backlog.

Estimated

Each backlog item has a development size estimate associated with it. If a large item makes it to the

top of the backlog, that is an indicator to the team that refinement must take place before it can be

moved into a sprint. Estimates are often based in story points or ideal days, which will be covered in

the next lecture.

Prioritized

More likely than not, only near-term backlog items are going to be prioritized – perhaps through a

release cycle. Since the product owner is constantly taking in new information, the priority of items

shifts based on customer input, organizational priorities, competitive or market influences.

While customers write the initial requirements, the development team begins to coauthor as the details

are refined. Schwaber (2007) recommends that the team spend 10% of its time on grooming activities.

Grooming may take place at any time – some teams may groom each day after their daily stand-up


meetings, others may do a deeper dive on it weekly, or even wait until the end of a sprint. Regardless of

the frequency, the Scrum team should get into the habit of grooming on a consistent basis. A well-

groomed backlog is a necessity for planning an iteration or sprint.


The Scrum Framework

Scrum Roles & Responsibilities

With its simple framework, Scrum is the most widely used agile software development methodology. In

this section, you will be introduced to the high-level Scrum framework, beginning with how Scrum fits

into the overall planning hierarchy of the organization, followed by an outline of the Scrum roles and

responsibilities, and an introduction to Scrum activities.

Jeff Sutherland and Ken Schwaber, the founders of Scrum, derived the methodology based on product

development improvement methods published by Hirotaka Takeuchi and Ikujrio Nonaka in 1986.

Sutherland began to apply the Scrum process to a software engineering project at Easel Corporate in

1993:

“We realized we needed a development process that fit an enhanced version of rapid

application development, where visualization of design could result immediately in working

code…Our…model was motivated by the Japanese approach to new product

development…What intrigued us was Hirotaka Takeuchi and Ikujiro Nonaka’s description of the

team-building process for setting up and managing a Scrum. The idea of building a self-

empowered team where everyone had the global view of the product on a daily basis seemed

the right one…The primary driver for beginning the first Scrum was absolute commitment to a

date, where failure would break the company…I told the CEO that in adopting Scrum, we set the

objectives at the beginning of what Scrum refers to as a sprint. It is the team’s responsibility to

determine how best to meet those objectives. During the sprint, no one can bother team

members with requests. At the end of a sprint…working code will be demonstrated so you can

see the progress made. You can decide to ship anytime or do another sprint to get more

functionality. Visible working code provides more confidence than extensive documentation

with no operational system.” (Sutherland, 2004)

With its lightweight project delivery approach and applicability to different types of projects, Scrum has

rapidly become one of the most widely used agile project management methods. Scrum leverages a

simple iterative framework structured into cycles called “sprints” of typically no more than 30 days in

duration. During a sprint, the development team selects customer requirements from the prioritized

product backlog. This allows the team to focus on functionality that will deliver the most value to the

customer. The goal at the end of each sprint is to demonstrate incremental functionality to the end

users for feedback. Sprints roll into a pre-determined release schedule; a release may encompass

several sprints.

The Scrum Team

The team is the most important component of the Scrum framework, and their goal is simple: Deliver

value to the customer. Scrum development teams self-organize around the work to be done and are

cross-functional in nature. They are responsible for determining how the work is done and self-

managing the work throughout the sprint.


The Scrum team composition is surprisingly simple, comprised of three key roles: Product owner,

ScrumMaster and the development team. The product owner determines what features the product will

contain and the sequence for developing those features. The ScrumMaster guides the team in following

Scrum processes and protecting the team from outside interference. The development team determines

how features will be delivered based on the product owner’s guidance. While there may be additional

roles on your particular Scrum team, these are the three required roles within the Scrum framework.

The Product Owner

The product owner provides the central point of product leadership and retains single authority for

determining the features and functionality that will be built within the system and the order for the

development of the functionality. In this leadership role, the product owner maintains and

communicates the product vision to the stakeholders and the Scrum team, and owns the ultimate

success of the product deliverables. Product owners are responsible for the work effort of the team and

their results. The Scrum team has an obligation to provide the product owner with all the information

she or he needs to make good business decisions.

The product owner plays a critical role on two fronts: The product owner balances the needs and

priorities of the organization, customers and end users, gives a single voice to the product as well as

providing guidance to the development team on the functionality that needs to be delivered to satisfy

stakeholder needs. The product owner drives the validation and verification process for determining

that features are satisfactorily delivered.

The product owner oversees economic decision-making at the release, sprint, and product backlog

levels. Release-level economic decisions include making continuous trade-offs in scope, date, budget,

and quality during product development. As new information is gathered, changes may occur during the

release cycle. An example trade-off might be an opportunity to add a feature that will dramatically

increase revenue, but result in a schedule slip. The product owner oversees this decision-making

process.

The product owner plays a critical role in portfolio, product, release and sprint-planning activities. At the

portfolio level, the product owner works with internal stakeholders, approval or governance committees

to ensure the product is positioned within the organization’s portfolio backlog. As product planning

work commences, the product owner works with stakeholders and customers to create a product vision.

At the release level, the product owner works with the stakeholders and development team to prioritize

features/functionality within a release cycle. Finally, as part of sprint planning, the product owner assists

the team in defining the sprint goal.

At the end of each sprint, the product owner also makes the determination on whether to fund the next

sprint. If the team is making good progress on the release goal, or the continuation of development is

economically viable, the next sprint will be funded. Funding for the project may be cancelled in the

event that the product is ready to ship. An example would be a project with a ten-sprint release. After

several sprints, the product owner reviews the remaining items in the product backlog and determines


that the cost of development isn’t worth the additional functionality. Shipping the product early may

make more sense.

The product owner is responsible for overseeing the “grooming” of the product backlog, which

represents features and functionality not yet developed. Grooming responsibilities include creating and

refining, and prioritizing backlog items. The development team performs the estimating with input or

clarification from the product owner.

Many organizations that begin to adopt Scrum often fail to encourage the right level of product owner

engagement with the development team. In the traditional “waterfall” development model, customer

engagement is high up front and then at the end of the project. In Scrum, product owner engagement is

high, consistent and level throughout the project. This helps mitigate the risk of developing a product

that doesn’t meet customer needs. Since Scrum develops products feature by feature, not phase, all of

the development activities required to complete a feature are completed within the sprint (design,

code, integrate, test), necessitating a high level of product owner involvement.

In addition to their responsibilities to the development process, the product owner is accountable for

maintaining and promoting the product vision. This includes all of the mechanisms for bringing a

product to market. Active participation is essential to the project – without the product owner’s

guidance, the Scrum team will not have a clear sense of priorities and may be working on the wrong

features.

The ScrumMaster

The ScrumMaster ensures that the Scrum team understands and embraces Scrum values. In this process

leadership role, the ScrumMaster helps the team and the organization develop their own specific Scrum

approach and facilitates the change management process in ensuring adoption of Scrum practices. As a

team facilitator and coach, the ScrumMaster helps remove impediments to the team’s progress and

productivity, and helps assists in making improvement to the team’s Scrum process. Unlike a traditional

project manager role, the ScrumMaster does not define the team’s work, but empowers the team to

determine how the work is accomplished.

The ScrumMaster role encompasses several responsibilities. ScrumMasters coach both the development

team and the product owner on an individual and whole-team basis. From Lyssa Adkins (2010),

“Coaching helps the team’s performance get better, in a series of steps coached by you and chosen by

them. Mentoring transfers your agile knowledge and experience to the team as that specific knowledge

becomes relevant to what’s happening with them.” Like a coach of a sports team, the ScrumMaster

enables the team to achieve higher levels of performance by helping the team work through any

challenges that arise during development.

ScrumMasters protect their teams from outside interference so the team can stay focused on the task at

hand. Outside interference can come from internal and external stakeholders (for example, let’s say a

vice president comes into the team’s war room in the middle of a sprint and asks for additional features


to be built in). The ScrumMaster intercepts interference and resolves issues that may interfere with the

team’s progress.

The ScrumMaster facilitates the removal of impediments to the team’s productivity. Impediments can

include problems outside of the team’s control (i.e. dependencies on other projects or teams). If the

team cannot remove the impediment, the ScrumMaster should take ownership of working with those

other teams to remove the impediment.

ScrumMasters change minds! As with any new process, there are cultural challenges in adopting Scrum

within the organization. As change agent, the ScrumMaster may be responsible for communicating and

championing the value of Scrum within the organization.

The Development Team

Unlike other methodologies that define specific development roles, the Scrum development team

incorporates a variety of job types, such as programmers, architects, testers, user interface (UI)

designers, database administrators, etc. The development team encompasses a diverse, cross-functional

group of resources who are responsible for developing the product vision.

Scrum empowers the development team to self-organize and determine how the work will be

performed. Typical teams are between five and nine people (if you have a larger team, you break them

into multiple scrum teams, which we’ll cover in our final module), but collectively the group must have

the skills needed to complete the work. Since quality assurance is an ongoing component of the

development process (and owned by the team), a Scrum team will typically not have a separate testing

role.

The cross-functional development team performs many responsibilities, including backlog grooming,

sprint planning and execution. The process of grooming includes creating, refining, estimating and

prioritizing product backlog items. While the product owner selects the high priority items, the

development team is responsible for determining what development work can be accomplished within

the sprint.

The development team participates in sprint planning prior to the execution of each sprint. Working

closely with the product owner (and facilitated by the ScrumMaster), the sprint goal is established. This

includes determining which high-priority features will be selected from the product backlog and

developed during the sprint. All of the development work takes place within the sprint execution. The

development team collectively determines how the work will be completed.

Additional Team Roles

While Scrum only requires three dedicated roles (Product Owner, ScrumMaster and Development

Team), you may find several other roles that are associated with the team. Agile methodologies like XP

have more granular role definition. Here are some additional roles you might find on an agile project:


Business Sponsor: While the product owner serves as the liaison between stakeholders and developers,

funding comes from an executive business sponsor within the organization. This is the person or entity

that provides funding for the project. The product owner is charged with execution.

Agile Coach: In Scrum, the ScrumMaster can serve as the coach. But for organizations that are just

starting down the path to agile delivery or have multiple Scrum teams across multiple projects, the

coach role may be separate. The coach is a process and enablement expert, providing advice and best

practices to the ScrumMaster, and helping teams become “unstuck” for particularly tough problems.

Coaching isn’t just for project administration – a separate programmer coach role may exist (often

informally). This person may have a technical lead role on the project, providing expertise to more junior

resources on the project.

Domain Specialists: Domain specialists – often called subject matter experts (or “SMEs”) provide the

deep business or functional expertise that a development team needs to understand a domain. For

example, if the team is building a financial application, the team will need SMEs that are experienced in

general accounting practices or industry regulations. SMEs are instrumental in creating tests that will

assist the team in implementing functionality or features correctly.

Business Analysts: The business analyst role augments the development effort by bridging the

communication and requirements gap often experienced between business stakeholders and the

development team. While the analyst doesn’t replace the customer role on the project, they can assist

in translating customer needs into development tasks.

Testers: In Scrum, the testing role is embedded within the development team. For more structured

methodologies like XP, the tester role can be separate. In XP, the tester serves as a technical investigator

for the team. This doesn’t relieve the developers of delivering error-free code, but provides a separate

line of defense for ensuring high-quality, bug-free deliverables.


Scrum Processes

In Scrum, development work is performed in short cycles known as “sprints” (also referred to as

iterations) that are typically 2-4 weeks in duration. The Scrum team and product owner determine the

length of the sprint, which should stay consistent through the duration of the project, and the number

of sprints within a release cycle. Sprints are time-boxed, that is, they have a defined start and end date.

The goal at the end of each sprint is to deliver working functionality to the hands of customers. A new

sprint directly follows a completed sprint unless the product is complete or there is no additional

funding available.

Since the items in the product backlog likely represent a significant duration of work – more than can be

completed in a single sprint – the product owner, development team and ScrumMaster perform sprint

planning at the beginning of each sprint.

In the sprint planning session, the team agrees on a sprint goal to determine what the sprint will

achieve. With the goal in mind, the team reviews the highest priority backlog items (prioritized by the

product owner; often represented as user stories) that they believe can be accomplished during the

sprint. Remember that a goal of Scrum is to ensure that the team works at a sustainable pace. This pace

should reflect the team’s normal working capabilities across an extended time period – not 80-hour

work weeks!

Think of the sprint goal as a vision statement for the sprint. The sprint goal defines the business purpose

and the value of the sprint. The purpose behind defining a shared sprint goal is to align the team during

sprint execution. The goal also helps determine which stories should be worked on by the team.

Sprint Capacity Planning

In determining whether the team has capacity to complete the desired product backlog items within the

sprint, the team breaks down the user stories into a set of tasks. This collection of stories and tasks

becomes the sprint backlog. The development team then estimates the work effort required to

complete each task. As a rule of thumb, tasks typically represent no more than eight hours of work

effort. When decomposed to this level, the team should have a good sense of the overall work effort

and its ability to fit within the sprint.

A key input into this process is the team’s velocity. Velocity is a measure of the team’s ability to

complete work per unit of time. In Scrum, velocity is calculated by summing the size estimates of the

product backlog items. For teams that are just starting to use Scrum, it may take a few sprints before the

team becomes comfortable with their ability to estimate work effort and complete work. Velocity is also

a measurement that is unique to a team – different teams will have different velocities and should not

be compared against each other.

As a rule of thumb, the sprint planning session is also time-boxed to approximately eight hours. The first

four hours are used for selecting product backlog and the second half is for preparing the sprint backlog.

The team uses the sprint backlog planning session to determine how the product backlog will be turned

into an increment of potentially shippable product functionality. The team makes this determination on


their own without outside influence from stakeholders or the product owner. At the end of the session,

the team has completed their sprint backlog, which includes tasks, task estimates and work

assignments. At this stage, the task list for the sprint might not be fully fleshed out, but contains enough

detail for the team to begin development work. As the sprint progresses, additional tasks can be added.

If the team finds that it has extra capacity within the sprint to take on more work, they can coordinate

with the product owner to select additional product backlog items.

Sprint Execution

Once sprint planning is complete, the team gets to work. As a self-organizing unit, the team defines how

the task-level work will be done and in what order to best accomplish the sprint goal. The 2-4 week

sprint timeframe is considered optimal for providing enough time for the team to produce deliverables,

while keeping the team from spending too much time overthinking their process by developing

unnecessary artifacts and documentation. The short duration of the sprint keeps customers interested

and engaged, since they know that they will be able to evaluate progress on a frequent basis.

Ken Schwaber (2009) recommends the following best guidelines for effective sprint execution:

• The team is allowed to seek outside advice, help, information, and support during the sprint; but

no one from outside can provide advice to the team

• The product backlog that the team commits to in sprint planning is frozen until sprint

completion

• If the sprint is not viable (for example, if the technology doesn’t work as planned or business

conditions have changed), the ScrumMaster can terminate the sprint and initiate a new planning

session

• If the team is unable to complete the work defined within the sprint, the team can consult with

the product owner on reorganizing or terminating the sprint

• If the team has capacity to take on more work during the sprint, they can consult with the

product owner to take additional backlog items

• Team members have two administrative responsibilities: they must attend daily Scrum meetings

and are responsible for keeping the sprint back-log up-to-date and visible to team members;

new tasks are actively added to the sprint backlog as they are defined and hours remaining on

tasks must be kept updated as well

Sprint Zero

While it may sound counterintuitive, the team may initiate iteration or sprint “zero” before beginning to

work on development tasks. Within sprint zero, the team focuses on getting things ready for the

development process so they can hit the ground running in their first sprint. This could include

developing the release plan and backlog, infrastructure set up and architectural design considerations,

establishing team practices and standards. Sprint zero can be useful in the following situations

(Rothman, 2012):

• The backlog may not yet exist: The team may use sprint zero to create the ranked backlog and

develop a “walking skeleton” or framework for the product


• The team is new: If your team hasn’t worked together before, use the opportunity to develop

working norms

• The environment is new: If the team doesn’t have any experience with a certain programming

language, software application or hardware configuration, take time to ensure that the team

understands the environment

• The team is geographically distributed: Use this opportunity to ensure that the team’s

communication/collaboration tools are working well and that the environment works from

different geographic locations

Sprint zero is not required, but may be useful for teams that are just getting started. As with any sprint,

the team should define a sprint goal to work towards. A successful sprint zero enables the team to begin

development quickly in sprint one.

Daily Stand-Up

At the start of each day, the Scrum team holds a daily Scrum meeting called the “daily stand-up” as part

of the inspect-and-adapt activities within Scrum. The daily stand-up meeting is no more than 15 minutes

in length and the team members give a round-robin status update by answering the following questions:

• What did I accomplish since the last daily stand-up?

• What do I plan to work on by the next daily stand-up?

• What are the obstacles or impediments that are preventing me from making progress?

The purpose of asking these questions is to ensure that team members are focused on the work at hand,

that they are progressing towards the sprint goal, and any issues that need to be addressed. Daily stand-

ups are not for problem-solving – problem-solving activities or conversations may take place outside of

the meeting.

“Chickens and Pigs”

There is a widely used analogy in Scrum that’s used to distinguish between those who are involved (the

chickens) and those who are committed to the sprint goal (the pigs). During a daily stand-up, the team

would be “pigs” and observers “chickens.”

Source: http://www.implementingScrum.com/images/060911-Scrumtoon.jpg

Are We Done Yet?

The outcome of the sprint results in a potentially shippable product increment. This is defined as having

work that’s been completed to the point where the features are customer-ready. The word “potential”

is important here, since the end of the sprint doesn’t mean that the product will be formally released.

The point is that the team is sufficiently confident that what was built during the sprint is complete.

What “done” means is defined by the Scrum team in advance. By creating a common definition of what

done means ensures that all team members and stakeholders are working with the same goal in mind.


Many organizations often report that something is complete when it is really only 80-90% finished. If the

meaning of “done” is clear and transparent, progress can be reported more accurately. “Done” is

different for each Scrum team and may be tied to acceptance tests, development standards, and/or

stakeholder sign-off.

The XP methodology uses a construct called “done-done.” This means that the completed story is ready

to deploy. Shore and Warden (2008) define story as complete when a customer can use it as intended.

The authors recommend the following criteria for story completion:

• All unit, integration and customer tests finished

• All code written

• All code designed and refactored to the team’s satisfaction

• The story is fully-integrated and works from end-to-end

• The build script

• includes the new modules

• includes the story in the automated installer

• migrates data where appropriate

• The story is reviewed by customer

• All known bugs are fixed

• Customers agree that the story is finished

Sprint Review

The sprint review, another inspect-and-adapt activity, provides the opportunity for the extended project

team to evaluate the completed sprint output. The extended team includes the Scrum team,

stakeholders, sponsors, customers and other interested parties. Getting feedback from stakeholders is

essential to ensuring the project stays on track and is viable.

Sprint review meeting preparation activities may include determining invitees, scheduling, confirming

that the work is complete, and preparing for the demo. While it sounds like a lot of work, the prep work

should be limited as the sprint review is an informal meeting with low ceremony and high value.

Ken Schwaber (2004) recommends the following sprint review best practices:

• Time-box the sprint review meeting to four hours; preparation work for the meeting should take

no longer than one hour

• The Scrum team presents to the product owner and stakeholders the completed functionality;

this is only functionality that has been deemed “done” by the team and product owner’s

definition

• Supporting artifacts are not presented unless they are needed to demonstrate functionality

• The review agenda should include: a team member presenting the sprint goal, the product

backlog the team agreed to complete during the sprint, and what was completed; it is

appropriate to discuss what went well and didn’t go well during the sprint, but it should not be

the focus of the meeting


• The bulk of the meeting is spent presenting functionality, answering questions and making notes

of any changes that stakeholders are requesting; stakeholders are free to provide open

feedback about the functionality that has been delivered

• The product owner takes that feedback and discusses potential rearrangement or new items to

be added to the product backlog

Sprint Retrospective

The final meeting within a sprint cycle is another inspect-and-adapt meeting: the sprint retrospective.

The retrospective occurs after the sprint review and before the next sprint planning meeting. This

meeting is attended by only the Scrum team and the product owner, and provides the group with the

opportunity to evaluate the team’s Scrum processes and technical practices. The outcome of the

retrospective is a number of process improvement actions that will be undertaken by the team during

the next sprint.

Per Schwaber (2009), the retrospective meeting is time-boxed to three hours and is facilitated by the

ScrumMaster. Each team member answers two questions: What went well during the last sprint? What

could be improved in the next sprint? The ScrumMaster collects the feedback, and the team prioritizes

the order of discussion items. The goal is to come away with action items that can be implemented

during the next sprint. Often, these action items are included within the product backlog.

The sprint retrospective is a low ceremony, high value meeting. Once the team develops a rhythm

around retrospective meetings, pre-work is minimal. A typical meeting includes:

Defining the retrospective focus: By default, the focus is to review all relevant processes used

by the Scrum team during the sprint. However, the team may select a different focus area if

there is something important to the team (examples could include improving test-driven

development skills or techniques for better understanding and interpreting customer

requirements).

Selecting exercises: Teams may elect to engage in exercises designed to help the group engage,

think, and explore together.

Gathering data: Data required for a retrospective should be collected prior to the meeting. For

example, if the team wants to analyze their velocity across a number of sprints, that data should

be available to the team during the meeting.

Structuring the retrospective: The retrospective is held after the sprint review, but can take

place in any location where the team feels comfortable engaging in their discussion. For some

teams, this meeting could take place in the team area, where all of the project artifacts are

visible. Other teams may prefer to hold the meeting in a more neutral or informal setting. While

the ScrumMaster might be a natural fit for the meeting facilitator, different development team

members can fill this role as well.


Identifying insights: During the meeting, the team will ask itself the following questions:

• What worked well?

• What didn’t work well?

• Where do we have opportunities to do things differently?

Determining actions: Once the team has prioritized their insights, they can begin brainstorming

action items to resolve them. While some action items may be implemented immediately,

others might have to be prioritized and/or added to an “insight backlog.” As with the product

backlog, the insight backlog should be continually groomed for relevance.

Following through: After the retrospective, nothing is more critical than following through on

action items. While some items can be reinforced by team members (i.e. showing up on time for

meetings), the team may add items from their insight backlog to the sprint backlog.

Summary

As we learned from our previous modules, when developing a product concept, we capture the voice of

the customer, and start envisioning our solution. We use a variety of user centric design methods, such

as user journeys, user flows, and concept maps to build out a set of capabilities that will be important to

our users. These capabilities start to form our product backlog. The product backlog provides the

backbone of your project requirements. This list of desired features and functionality of the system is

groomed continually throughout the project according to DEEP principles. The grooming process can be

performed by the team throughout the project duration.

A prioritized list of backlog items is sequenced in the form of a product roadmap, which evolves over

time as new needs or requirements are captured. The roadmap is aligned to a delivery timeline, called a

release plan. The release plan sets the expectations around what we will be delivering to our users and

when.

We start to develop our solution using Scrum. Scrum work is organized into fixed duration iterations or

cycles called sprints. There is a sequence of activities within every sprint related to planning, execution,

review and retrospective. Sprints are time-boxed events of approximately 2-4 weeks in duration. Prior to

sprint execution, a planning session takes place where the team decomposes the high priority backlog

items into tasks. When execution begins, the team comes together for a daily stand-up meeting to

discuss what’s being worked on and if there are any impediments. The execution closes with a sprint

review, where the team reviews the completed user stories with the product owner and customers.

Finally, the team closes out the sprint with a retrospective that allows them to celebrate achievements

and identify team process improvement opportunities.

Remember that the most important part of the Scrum process is the team, and their purpose is to

deliver value to the customer. Scrum teams have three primary roles: The Product Owner, the Scrum

Team and the ScrumMaster. Product owners provide product leadership and are accountable to the


business and end-customers of the product. The Scrum Team executes on the product vision in short

iterative cycles. Scrum teams are self-organizing and cross-functional. The ScrumMaster is the Scrum

process authority, and ensure that the team is adhering to Scrum processes. The ScrumMaster also

protects the team from outside interruptions, so the team can focus on high-quality deliverables. In

addition to the three key roles, a number of other roles may exist internally and externally to the team

depending on the agile methodology used or other organizational requirements.


References

Adkins, L. (2010). Coaching agile teams a companion for ScrumMasters, agile coaches, and project

managers in transition. Upper Saddle River, NJ: Addison-Wesley.

Cohn, M. (2013). User stories applied: For agile software development. Boston: Addison-Wesley.

Patton, J. (2014). User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA:

O’Reilly Media.

Pichler, R. (2010). Agile Product Management with Scrum: Creating Products that Customer Love.

Boston: Addison-Wesley.

Rothman, J. (2012). How to Use Iteration Zero – Or Not. Retrieved online from:

https://www.jrothman.com/articles_/2012/10/how-to-use-iteration-zero-or-not/

Schwaber, K. (2004). Agile Project Management with Scrum. Redmond, WA: Microsoft Press.

Shore, J. & Warden, S. (2008). The Art of Agile Development. Sebastopol, CA: O’Reilly Media.

Sutherland, J. (2004). Agile Development: Lessons Learned from the First Scrum. Retrieved online from:

https://www.researchgate.net/publication/251784359_AGILE_DEVELOPMENT_LESSONS_LEARNED

_FROM_THE_FIRST_SCRUM

Module 3 Creating the Product Roadmap€¦ · delivering on a release timeline. The roadmap is a...

Documents

Transcript of Module 3 Creating the Product Roadmap€¦ · delivering on a release timeline. The roadmap is a...