Agile Planning and Execution
Follow the Roadmap to Value, from vision to execution
Create working functionality and showcase it in iterations
Pavel Adámek
Project management

Outline of the lecture
•
•Defining the Product Vision and Product Roadmap
•
•Planning Releases and Sprints
•
•Working throughout the Day
•
•Showcasing Work, Inspecting, and Adapting
•
•
•

Introduction
•Agile projects, in contrast, involve planning upfront and throughout the entire project. By
planning at the last responsible moment, right before an activity starts, you know the most about
that activity.
•
•This type of planning, called just-in-time planning or a situationally informed strategy, is a key
to agile project success.
•
•Agile teams plan as much as, if not more than, traditional project teams. However, agile planning
is more evenly distributed throughout the project and is done by the entire team that will be
working on the project.
•
•The agile focus on just-in-time planning allows you to accommodate real situations and to be well
informed as you plan specific tasks.

Defining the Product Vision and Product Roadmap
You will plan not only the overall project but also every release, every sprint, and every day.
Planning is fundamental to agile project success.
•Planning happens at a number of points in an agile project.
•
•A great way to look at the planning activities in agile projects is with the Roadmap to Value.
•
•Each stage in the Roadmap to Value is repeatable, and each stage contains planning activities.
Agile planning, like agile development, is iterative.

Agile Planning
The Roadmap to Value has seven stages:
•In stage 1, the product owner identifies the product vision. The product vision is your project’s
destination or end goal. The product vision includes the outer boundary of what your product will
be, how the product is different from the competition, how the product will support your company or
organization’s strategy, who will use the product, and why people will use the product.
•In stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view
of the product requirements, with a general time frame for when you will develop those
requirements. It also gives context to the vision by showing the tangible features that will be
produced during the project. Identifying product requirements and then prioritizing and roughly
estimating the effort for those requirements allow you to establish requirement themes and identify
requirement gaps.
•In stage 3, the product owner creates a release plan. The release plan identifies a high-level
timetable for the release of working functionality to the customer. The release serves as a
mid-term boundary against which the scrum team can mobilize. An agile project will have many
releases, with the highest-priority features appearing first. You create a release plan at the
beginning of each release, which is usually at least quarterly.

Agile Planning
The Roadmap to Value has seven stages:
•In stage 4, the product owner, the development team, and the scrum master will plan iterations,
also called sprints, and start creating the product functionality in those sprints. Sprint planning
sessions take place at the start of each sprint. During sprint planning, the scrum team determines
a sprint goal, which establishes the immediate boundary of work that the team forecasts to
accomplish during the sprint, with requirements that support the goal and can be completed in the
sprint.
•In stage 5, the development team has daily scrum meetings during each sprint to coordinate the
day’s priorities. In the daily scrum meeting, you discuss what you completed yesterday, what you
will work on today, and any roadblocks you have, so that you can address issues immediately.
•In stage 6, the scrum team holds a sprint review at the end of every sprint. In the sprint review,
you demonstrate the working functionality to the product stakeholders.
•In stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting
where the scrum team discusses the completed sprint with regard to their processes and environment,
and makes plans for proces improvements in the next sprint.

Agile Planning
Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management
Overview of the roadmap to value in agile project management
•

Defining the Product Vision and Product Roadmap
•The first stage in an agile project is defining your product vision. The product vision statement
is an elevator pitch, or a quick summary, to communicate how your product supports the company’s or
organization’s strategies. The vision statement must articulate the end state for the product.
•
•The product might be a commercial product for release to the marketplace or an internal solution
that will support your organization’s day-to-day functions.
•
When creating a product vision statement, follow these four steps:
•Develop the product objective.
•Create a draft vision statement.
•Validate the vision statement with product and project stakeholders and revise it based on
feedback.
•Finalize the vision statement.
•

Defining the Product Vision and Product Roadmap
•The product roadmap, stage 2 in the Roadmap to Value, is an overall view of the product’s
requirements and a valuable tool for planning and organizing the journey of product development.
•Use the product roadmap to categorize requirements, prioritize them, identify gaps and
dependencies, and determine a timetable for releasing to the customer.
•As he or she does with the product vision statement, the product owner creates the product
roadmap, with help from the development team and stakeholders. The development team participates to
a greater degree than it did during the creation of the vision statement.
•
To create your product roadmap, you do the following:
•Identify stakeholders.
•Establish product requirements and add them to the roadmap.
•Arrange the product requirements based on values, risks, and dependencies.
•Estimate the development effort at a high level and prioritize the product’s requirements.
•Determine high-level time frames for releasing groups of functionality to the customer.
•
•

Defining the Product Vision and Product Roadmap
•The product roadmap contains high level features and some tentative release timelines. The
requirements on your product roadmap are the first version of your product backlog.
•The product backlog is the list of all requirements associated with the project.
•The product owner is responsible for creating and maintaining the product backlog by adding and
prioritizing requirements.
•
•The scrum team uses the prioritized product backlog throughout the project to plan its work - like
a streamlined project plan.
•
At a minimum, when creating your product backlog, be sure to do the following:
•Include a description of each requirement.
•Order the requirements based on priority.
•Add the effort estimate.
•

Planning Releases and
Sprints
After you create a product roadmap for your agile project, it’s time to start elaborating on your
product details.
The concept of breaking down requirements into smaller pieces is called decomposition.
•You start agile projects with very large requirements.
•
•As the project progresses and you get closer to developing those requirements, you will break them
down into smaller parts - small enough to begin developing.

Planning Releases and Sprints
•Your customers and stakeholders provide requirements for the product owner to vet for placement on
your product backlog. Your customers may or may not be the same people who will use your product.
•
• Knowing who your end users are and how they will interact with your product drive how you define
and implement each requirement on your product roadmap.
•
•We like to define users using personas, or a written description about a type of user represented
by a fictitious person.
•Know who your users are, so you can develop features they’ll actually use.
•
•Be sure to continuously add and prioritize new user stories to your product backlog. Keeping your
product backlog up-to-date will help you have the highestpriority user stories when it is time to
plan your sprint.
•
•

Planning Releases and Sprints
•To decompose requirements, you’ll want to think about how to break down the requirement into
individual actions.
•
You refine requirements many times throughout an agile project. For example:
•When you create the product roadmap, you create features (capabilities your customers will have
after you develop the features), as well as themes (logical groups of features). Although features
are intentionally large, we require features at the product roadmap level to be no larger than 144
story points on the Fibonacci scale.
•When you plan releases, you break down the features into more concise userstories. User stories at
the release plan level can be either epics, very large user stories with multiple actions, or
individual user stories, which contain a single action. For our clients, user stories at the
release plan level should be no larger than 34 story points. You find out more about releases later
in this chapter.
•When you plan sprints, you can break down user stories even further. You also identify individual
tasks associated with each user story in the sprint. For our clients, user stories at the sprint
level should be no larger than eight story points. Tasks will be estimated in hours and should be
no larger than what can be accomplished in a day.
•

Planning Releases and Sprints
•A release is a group of usable product features that you deploy to the market.
•A release does not need to include all the functionality outlined in the product roadmap but
should include at least the minimal marketable features, the smallest group of product features
that you can effectively deploy and promote in the marketplace.
•
•Your early releases will exclude many of the medium- and low-priority requirements you identified
during the product roadmap stage.
•
•When planning a release, you establish the next set of minimal marketable features and identify an
imminent product launch date around which the team can mobilize.
•
As when creating the vision statement and the product roadmap, the product owner is responsible for
creating the release goal and establishing the release date. However, the development team’s
estimates, with the scrum master’s facilitation, contribute to the process.

Planning Releases and Sprints
Release planning involves completing two key activities:
•Revising the product backlog:  the product backlog is a comprehensive list of all the user stories
you currently know for your project, whether or not they belong in the current release. Keep in
mind that your list of user stories will probably change throughout the project.
•Creating the release plan: This activity consists of the release goal, release target date, and
prioritization of product backlog items that support the release goal. The release plan provides a
midrange goal that the team can accomplish.
•
•Don’t create a new, separate backlog during release planning. The task is unnecessary and reduces
the product owner’s flexibility. Prioritizing the existing product backlog based on the release
goal is sufficient and enables the product owner to have the latest information when he or she
commits to the scope during sprint planning.
•
•The product backlog and release plan are some of the most important communication channels between
the product owner and the development team.

Planning Releases and Sprints
•In agile projects, a sprint is a consistent iteration of time in which the development team
creates a specific group of product capabilities from start to finish.
•At the end of each sprint, the functionality that the development team has created should be
working, ready to demonstrate, and potentially shippable to the customer.
•
•Sprints generally last one to four weeks. Four weeks is the longest amount of time any sprint
should last; longer iterations make changes riskier, defeating the purpose of being agile. We
rarely see sprints lasting longer than two weeks, and more often see sprints lasting a week.
•
•One-week sprints are a natural cycle with the Monday-to-Friday business week that structurally
prevents weekend work. Some scrum teams work in one-day sprints where priorities change on a daily
basis.
•
•Market and customer needs are changing more and more quickly, and the amount of time you can
afford between opportunities to gather customer feedback only gets shorter. Our rule of thumb is
that your sprint shouldn’t be longer than your stakeholders can consistently go without changes in
priority regarding what the scrum team should be working on in the sprint.
•
•
•

Planning Releases and Sprints
Each sprint includes the following:
•Sprint planning at the beginning of the sprint
•Daily scrum meetings
•Development time — the bulk of the sprint
•A sprint review and a sprint retrospective at the end of the sprint
•
The sprint backlog is a list of user stories associated with the current sprint and related tasks.
When planning your sprint, you do the following:
•Establish goals for your sprint.
•Choose the user stories that support those goals.
•Break user stories into specific development tasks.
•Create a sprint backlog. The sprint backlog consists of the following:
•The list of user stories within the sprint in order of priority.
•The relative effort estimate for each user story.
•The tasks necessary to develop each user story.
•The effort, in hours, to complete each task.
•
•

Working throughout the Day
The work that you will do every day as part of a scrum team: planning
and coordinating your day, tracking progress, creating and verifying usable functionality, and
identifying and dealing with impediments to your work.
•On agile projects, you make plans throughout the entire project - and on a daily basis.
•
•Agile development teams start each workday with a daily scrum meeting to note completed items, to
identify impediments, or roadblocks, requiring scrum master involvement, and to synchronize and
plan what each team member will do during the day to achieve the sprint goal.

Working throughout the Day
•The daily scrum is Stage 5 on the Roadmap to Value.
In the daily scrum meeting, each development team member makes the following three statements,
which enable team coordination:
•Yesterday, I completed (state items completed).
•Today, I’m going to take on (state task).
•My impediments are (state impediments, if any).
We also have the scrum master address these three statements regarding the team’s impediments:
•Yesterday, I resolved to (state impediments completed).
•Today, I’m going to work on removing (state impediment).
•The impediments I’m going to escalate are (state impediments you need assistance with, if any).
•
•
Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management

Working throughout the Day
•You also need to track the progress of your sprint daily. This section discusses ways to keep
track of the tasks in your sprint.
•
•Two tools for tracking progress are the sprint backlog and a task board. Both the sprint backlog
and the task board enable the scrum team to show the sprint’s progress to anyone at any given time.
•
•The Agile Manifesto values individuals and interactions over processes and tools. Make sure your
tools support, rather than hinder, your scrum team.
•
•During sprint planning, you concentrate on adding user stories and tasks to the spring backlog.
During the sprint itself, you update the sprint backlog daily, tracking progress of the development
team’s tasks for each working day.
•
•Make the sprint backlog available to the entire project team every day. That way, anyone who needs
to know the sprint status can find it instantly.

Working throughout the Day
•the sprint burndown chart, which shows the progress that the development team is making. You can
see that the development team members have completed tasks close to the even burn rate of their
available hours, and the product owner has accepted several user stories as complete.
•
•You can include burndown charts on your sprint backlog and on your product backlog.
•
A burndown chart is a powerful tool for visualizing progress and the work remaining. The chart
shows the following:
•The outstanding work (in hours) on the first vertical axis
•Time, in days along the horizontal axis
Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management

Working throughout the Day
•Although the sprint backlog is a great way to track and show project progress, it’s probably in an
electronic format, so it might not be immediately accessible to anyone who wants to see it.
•
•Some scrum development teams use a task board along with their sprint backlog.
•
•A task board provides a quick, easy view of the items in the sprint that the development team is
working on and has completed.
•
•We like task boards because you can’t deny the status they show.
•
•Like the product roadmap, the task board can be made up of sticky notes on a whiteboard.

Working throughout the Day
The task board will have at least the following four columns, from left to right:
•To Do: The user stories and tasks that remain to be accomplished are in the far left column.
•
•In Progress: User stories and tasks that the development team is currently working on are in the
In Progress column. Only one user story should be in this column. Having more user stories in
progress is an alert that development team members are not working cross-functionally and, instead,
are hoarding desired tasks. You risk having multiple user stories partially done instead of more
user stories completely done by the end of the sprint.
•
•Accept: After the development team completes a user story, it moves it to the Accept column. User
stories in the Accept column are ready for the product owner to review and either provide feedback
or accept.
•
•Done: When the product owner has reviewed a user story and verifies that the user story is
complete, the product owner can move that user story to the Done column.

Working throughout the Day
•A typical task board. As you can see, the task board is a strong visual representation of the work
in progress.
•The task board shows four user stories, each separated by a horizontal line called swim lanes.
•The first user story is done.
•All tasks are completed, and the product owner has accepted the work done.
•For the second user story, the development work is completed but is waiting for acceptance by the
product owner.
•The third user story is in progress, and the fourth user story has not yet been started.
•At a glance, the status of each user story is clear not only to the scrum team, making tactical
coordination faster and easier, but also to interested stakeholders.
Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management

Working throughout the Day
•Limit your work in progress! Only select one task at a time. Leave other tasks available in the To
Do column.
•
•Ideally, a development team will work on only one user story at a time and swarm on the tasks of
that user story to complete it quickly.
•
•Because the task board is tactile -  people physically move a user story card through its
completion -  it can engage the development team more than an electronic document ever could.
•
•The task board encourages thought and action just by existing in the scrum team’s work area, where
everyone can see the board.
•
•At the end of each day, the development team reports on task progress by updating the sprint
backlog with which tasks were completed and how much work, in hours, remains to be done on new
tasks started.

Showcasing Work, Inspecting, and Adapting
At the end of each sprint, the scrum team gets a chance to put the results of its hard work on
display in the sprint review.
•The sprint review is where the product owner and the development team demonstrate the sprint’s
completed, potentially shippable functionality to the stakeholders.
•
•In the sprint retrospective, the scrum team (the product owner, development team, and scrum
master) review how the sprint went and determine whether they need any adjustments for the next
sprint.
•
•Underpinning both of these events is the agile concept of inspect and adapt.

Showcasing Work, Inspecting, and Adapting
•The sprint review is a meeting to review and demonstrate the functionality created from the user
stories that the development team completed during the sprint, and for the product owner to collect
feedback and update the product backlog accordingly.
•
•The sprint review is open to anyone interested in reviewing the sprint’s accomplishments.
•
•This means that all stakeholders get a chance to see product progress and accuracy, and provide
feedback.
•
•The sprint review is stage 6 in the Roadmap to Value.
•
•
Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management

Showcasing Work, Inspecting, and Adapting
•Preparation for the sprint review meeting should not take more than a few minutes at most. Even
though the sprint review might sound formal, the essence of showcasing for agile teams is
informality.
•
•The meeting needs to be prepared and organized, but it doesn’t require a lot of flashy materials.
Instead, the sprint review focuses on demonstrating what the development team has done.
•
•The preparation for the sprint review meeting involves the product owner and the development team,
facilitated by the scrum master as needed. The product owner needs to know which user stories the
development team completed during the sprint. The development team needs to be ready to demonstrate
completed, shippable functionality.
•
•The time needed to prepare for a sprint review should not be more than 20 minutes -  just enough
time to make sure everyone knows who is doing what and when so the demonstration goes smoothly.

Showcasing Work, Inspecting, and Adapting
For the development team to demonstrate the code in the sprint review, it must be complete
according to the definition of done. This means that the code is fully
•Developed
•Tested
•Integrated
•Documented
•
•As user stories are moved to a status of done throughout the sprint, the product owner and
development team should check that the functionality meets these standards. This continuous
validation throughout the sprint reduces end-ofsprint risks and helps the scrum team spend as
little time as possible preparing for the sprint review.
•
•Sprint review meetings have two activities: demonstrate and showcase the scrum team’s finished
work, and allow stakeholders to provide feedback on that work.

Showcasing Work, Inspecting, and Adapting
•Each day, development team members work together in a collaborative environment that encourages
feedback through peer reviews and informal communication.
•Throughout each sprint, as soon as the development team completes each requirement, the product
owner provides feedback by reviewing the working functionality for acceptance. The development team
then immediately incorporates that feedback, if any, to satisfy the user story’s acceptance
criteria.
•At the end of each sprint, project stakeholders provide feedback about completed functionality in
the sprint review meeting.
•With each release, customers who use the product provide feedback about new working functionality.
Source: Layton, M. C., Ostermiller S. J. 2017. Agile Project Management

Showcasing Work, Inspecting, and Adapting
•The sprint retrospective is a meeting in which the product owner, development team, and scrum
master discuss how the sprint went and what they can do to improve the next sprint. The scrum team
should conduct this meeting in a selfdirected way.
•
•If managers or supervisors attend sprint retrospectives, scrum team members will avoid being open
with each other, which limits the effectiveness of the team inspecting and adapting in a
self-organizing way.
•
•If the scrum team likes, members can invite other stakeholders to attend as well. If the scrum
team regularly interacts with outside stakeholders, those stakeholders’ insights can be valuable.
•
•The sprint retrospective is stage 7 in the Roadmap to Value.

Showcasing Work, Inspecting, and Adapting
•The sprint retrospective is one of the best opportunities you have to put the ideas of inspect and
adapt into action.
•
•You came up with challenges and solutions during the retrospective. Don’t leave those solutions
behind after the meeting; make the improvements part of your work every day.
•
•You could record your recommendations for improvement informally. Some scrum teams post the
actions identified during the retrospective meeting in the team area to ensure visibility and
action on the items listed.
•Many teams also add action items to the product backlog to ensure that they implement them during
an upcoming sprint.
•
•To become more agile, scrum teams focus on small changes with big value. We like teams to take at
least one improvement into each sprint, a process sometimes referred to as scrumming the scrum.

RECAP
•Agile projects involve planning upfront and throughout the entire project. By planning at the last
responsible moment, right before an activity starts, you know the most about that activity. This
type of planning, called just-in-time planning or a situationally informed strategy, is a key to
agile project success.
•
•Agile teams plan as much as, if not more than, traditional project teams. However, agile planning
is more evenly distributed throughout the project and is done by the entire team that will be
working on the project.
•
•Each stage in the Roadmap to Value is repeatable, and each stage contains planning activities.
Agile planning, like agile development, is iterative.
•
•Day-to-day work on an agile project involves more than just planning and tracking progress. In the
next section, you see what most of your day’s work will include, whether you’re a member of the
development team, a product owner, or a scrum master.
•
•