Breakthrough products don’t arise from thinking small. They arise from thinking big and responding to change better than everyone else. From asking the question: What’s the best way to solve this problem?

Agile planning and product roadmapping help to answer that question in safe, controlled iterations. From your vision, you set goals. From your goals, you define desired outcomes. Then, to achieve those outcomes, you focus on answering the questions: what needs to be built, when it needs to be completed, how much will it cost, and who needs to be involved.

Project managers will also want to know any dependencies between activities so they can minimize idle time and optimize the schedule. After that, you can launch a series of experiments in sprints and iterations to meet those outcomes. If you meet them, you move onwards. If you don’t? Take a coffee break, then pivot.

Agile Planning Processes and Methods

Agile planning activities for large-scale development efforts can be broken down into five levels:

  • Product Vision
  • Product Roadmap
  • Release Plan
  • Iteration/Sprint Plan
  • Daily Commitment / Scrum

Level 1 – Product Visioning

Before the start of an Agile project, your organization needs to identify a project vision and a business case to execute on that vision. Visioning exercises are helpful at this stage, with the goal of creating a statement that describes what an organization or product should look like after the project finishes in terms of desired product features, target customers, and key differentiators from previous or competitive products. This helps the Product Owner indicate what parts of the system need to change (establishing priority) and what efforts can be used to achieve this goal, including team formation and high-level time and cost estimation.

Further Agile planning activities will detail the vision, and may even divert from the vision because the future may bring a changed perspective on the market, the product, and the required efforts to make the vision real.

Level 2 – Product Roadmap

The era of large-scale projects that deliver results in years is behind us. Customers demand more frequent changes, and time-to-market is now measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps – into thinking of a road towards the final product. Just like a journey is planned upfront and shared with fellow travelers, a product roadmap is created and communicated to fellow delivery people.

The goals of creating a Product Roadmap are for the Product Owner to:

  • Communicate the whole
  • Determine and communicate when releases are needed
  • Determine what functionality is sufficient for each release
  • Focus on the business value derived from the releases

The delivery team, on the other hand, will:

  • See the whole
  • Learn about the steps to realize the vision
  • Learn the business priorities
  • Provide technical input to the roadmap
  • Provide estimates for the projected features

The creation of the Product Roadmap is largely driven by the Product Owner in a single meeting or a series of meetings. This can be done, quite literally, through a graphical representation of the releases, or more formally in a written document outlining dates, contents, and objectives of the foreseen releases.

In anticipation of the next Agile planning stage, a list of desired features also needs to be built into the roadmap – this is the product backlog. In its simplest form, the backlog is a list of product requirements so the delivery team can provide estimates for delivery of each feature.

Because the success of an Agile project depends on the early delivery of the highest priority features, the list must be prioritized. And because the success of a project is measured in business terms, the prioritization of the feature list is the responsibility of the business, i.e. the Product Owner. Interaction with the delivery teams is required throughout the product roadmapping process because, without a discussion of the features, it will be hard for the delivery team to produce estimates that have an acceptable level of inaccuracy (remember, these estimates will be changing as the product moves along the software delivery lifecycle).

Level 3 – Release Planning

The next two levels involve the planning of releases and iterations. Your organization may decide to release each iteration to the customer when it becomes available or release a collection of iterations at once in one defined release.

A release is what the name implies: a set of product increments that is released to the customer.

Characteristics of a release:

  • Releases are defined by date, theme, and planned feature set
  • Scope, not date or quality, is the variable, which highlights the need to use a prioritized product backlog as the basis of a planning event
  • All teams must commit to the same rhythm of iterations. When all teams work to the same rhythm, the discovery and management of dependencies occurs automatically during the planning activities
  • There are fixed release dates across all teams of the program with a typical interval of two to four months

Release vs. Iteration – What’s the difference?

A release is defined at the system or program level, usually in product owner vocabulary. The release theme, release date, and prioritized features together form a release as defined by the product owner. When releases are seen in the perspective of the roadmap, the highest level of visibility and confidence are in the current and next release. Near-term releases have more detail in the feature descriptions and have smaller individual features. A release can stretch over six to nine months, although two to four months is more common.

An iteration, on the other hand, is defined at the feature level. The delivery team and product owner have agreed on the number of iterations in a release. Features delivered in an iteration are determined by the priority, and the number of features delivered is set by the velocity of the team and the team estimates of the features. Iteration lengths vary from one to six weeks, with two weeks as the most frequent duration.

During release planning, the project manager, product owner, project team, and other stakeholders break the functionality in the product backlog into a number of iterations, ensuring that each iteration can be completed within the duration of an iteration. They then assign iterations to releases, creating a release backlog. Every release delivers a working product increment.

Based on this release plan, the dates for the release milestones, as well as for the final product release, can be identified. The overall project cost can be determined by calculating the labor cost of the team and the number of identified iterations. Overhead and material costs have to be added to this number. The chart below shows the inputs, tools and techniques, and outputs for the release planning process.

 Inputs      Tools & Techniques  Outputs
Product Vision
Product Roadmap
Prioritized Product Backlog
Estimated or Measured Team
Velocity
Planning Meeting
Brainstorming
Dependency Determination
Speculation
Expert Judgement
Analogous Estimating
 Release Plan
– Assumptions
– Risks
– Action Items
– Dependencies
– Release Backlog
Top-down Cost Estimate and Updates

How to Conduct Release Planning

A release planning session typically takes place over a full day, or sometimes two if the product is very large (hundreds of team members). All team members participate in the session, including the product owner, full delivery team, and stakeholders. Release planning should be highly collaborative and interactive, and the tools used are typically sticky notes, flip charts, and whiteboards. Once established, the results will be managed and communicated in an Agile planning and project management tool.

Example agenda for release planning meeting:

  • Introductions, goals, agenda updates
  • Product vision explanation by the product owner
  • Time-boxes for the releases and iterations
  • Capacity calculation by the delivery team
  • Agreement of deliverables (when is a feature ‘Done’)
  • Moving features from the backlog into the iterations within the release by the individual teams
  • Determination of dependencies by walking all the teams through the individual planning results and moving features to alternative iterations to solve the
  • dependencies within and between teams
  • Final calculation of workload per iteration and comparison with the available capacity
  • Review of discovered risks and issues
  • Retrospective of the session

Level 4 – Iteration/Sprint Planning

For each iteration within a release, a planning session should take place to add detail and increase accuracy. Before or during the session, detail is added to the features by decomposing them into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

The structure of the iteration planning session resembles release planning, but with the prime distinction of the planning horizon – only a single iteration. Although the teams work individually to produce their iteration plan, synchronization between teams provides an effective mechanism to detect and resolve dependencies.

Iteration planning activities are carried out on a team-by-team basis:

  • Individual teams determine their actual capacity or the amount of work they can get done within the iteration
  • Individual teams decompose as many features as seem to fit in the next iteration into tasks
  • Every task is estimated, with a typical task size of a half-day to two days
  • The ‘done’ definition is taken into consideration – a feature is not done until it has been fully tested and accepted by the product owner
  • The results of the individual teams are inspected in a joined session to determine dependencies (or the disappearance of them) that were not seen during the release planning session

At the beginning of the iteration planning meeting, the team verifies that there is agreement on the product backlog and the priority of the listed features. Reprioritization will happen if needed, for example, when the team is unclear with the current order of features listed in the product backlog (step 1). After getting more detail on the features from the customer (if needed), the development team chooses features from the product backlog they think can be accomplished within the next iteration (step 2). In step 3 the team identifies the tasks (user stories) required to implement the chosen features, identifies initial task sequencing, assigns task owners, and estimates tasks (time). During step 3 the team might discover that the effort to complete the chosen features is more or less than the time allotted for the iteration. As a result, features might be removed or added to the iteration backlog (step 4). When functionality is moved back to the product backlog, it can lead to a reprioritization of the product backlog.

Because the Agile planning process is iterative, the team might go through the full planning circle several times. At the same time, planning meetings should be limited to four hours. The guideline is that the team should not spend more than two meetings to identify the scope and tasks of the next iteration. The idea behind this is that the team learns from its actions and becomes better at estimating over time.

After a number of completed iterations, the team members can measure their team velocity, which is the average time they spent on implementing one feature. When they understand and know their team velocity, they can come up faster with their estimates during their planning meetings. Since iterations are short (one to six weeks), uncertainty is limited and estimates are, in general, quite good.

Sprint Review

A Sprint Review is held at the end of the sprint or iteration to inspect the increment and adapt the Product Backlog if needed.

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the iteration, and the time to complete the full project can be recalculated based on the results of the previous iteration and any changes to the product backlog, including priority changes or adding or deleting features on the product backlog.

The scope is only locked in for the duration of the ongoing iteration. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

Because the product backlog can be modified throughout the duration of the project, the number of iterations and releases are subject to change as well. If fewer features or more features are selected during the planning of the next iteration, the content and number of future iterations could change, and as a result, the collection of iterations assigned to one release could change as well.

Sprint Retrospective

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning and is an opportunity for your cross-functional Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master ensures that the meeting is positive and productive and participates as a peer team member in the meeting.

Purpose of the Sprint Retrospective:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Level 5 – Daily Planning / Scrum

The scrum meeting, also known as the daily stand-up, is part of everyday life for Agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

Keeping your Scrum Meeting on Track:

Let’s be clear. Everyone does stand-ups a little differently, and that’s okay. Below are the tips and tricks we’ve found to help your scrum meeting run like a lean, mean, effective machine. But no matter what you do, ensure that focus and efficiency are priorities for the scrum.

1. Remain standing – It may sound like a gimmick. It may sound like a formality. But trust us, it’s not. Staying on your feet is the core principle of the scrum meeting. It reduces rambling and keeps you focused. An easy solution to eliminate sitters? Hold the meeting in a room without chairs or keep all chairs on one side of the room. Forcing someone to go out of their way to pull up a chair is an excellent way of silently keeping your team on their feet.

2. Your 3 question agenda – The scrum meeting, in an Agile development world, has every team member answer three simple questions: 1) What did you accomplish since the last meeting?* 2) What are you working on until the next meeting? and 3) What is getting in your way or keeping you from doing your job? This tells the team exactly what is getting done and what needs improvement. Listing any problems or issues you may have is crucial so that your team will know to help you out. And small problems should always be addressed so that they don’t turn into big problems.

*Note: The answer to the first question should only be a brief mention. Far more time should be spent talking about current tasks and the issues you may face.

3. Have your Agile planning and project management tool visible – Whether it’s in the form of a physical kanban board or software like Storyteller — it’s important for your team to see what is being finished and what is taking longer than expected. This is especially helpful for teams that spend too long answering question #1. Also, getting everyone into the habit of reviewing your Agile planning tool right before the meeting results in a big efficiency boost.

4. Make sure it’s a collaborative effort – One of the most common scrum meeting mistakes is making it a turn-based 1:1 chat with the project manager or scrum master. This completely defeats the purpose of the stand-up and should be avoided at all costs. This is valuable time that should be treated as a collaborative effort for the whole team. A good way to keep scrum meetings efficient is to establish a simple rule: Everything you say should be valuable to everyone in the room. Individual talks can happen at any time of the day aside from the stand-up meeting.

5. Plan the meeting around your team – Sometimes it’s impossible to adhere to a strict schedule, but it’s important to develop some sort of routine for your stand up meetings. Whether you have it every day or every week, consistency is key. If your team gets to the office early every day, hold your meetings first thing in the morning as to not interrupt valuable work time. Is your team’s arrival staggered? Do your teammates have other commitments in the morning? Hold your stand-ups in the afternoon. The scrum meeting is less about strict rules and more about maximizing productivity. Turning the daily or weekly stand up into a regular routine that accommodates your team’s unique schedule helps ensure scrum meetings are an effective planning tool for your development team.

Scrum of Scrums

Like other Agile planning activities, daily scrum meetings need to be synchronized between teams as well. This takes place in a coordinated ‘Scrum of Scrums’ meeting that happens on a weekly schedule (or daily if it is late in the release cycle). Representatives from each individual team meet to report the status, plans, and impediments to each other in an identical format as in the individual meetings:

  • How are all the teams progressing?
  • What are teams tackling next?
  • What are the cross-team impediments and who is taking the actions to remove them?

The principle of a scrum meeting can be repeated to address large numbers of teams, where representatives of ‘teams of teams’ report on the progress of the ‘teams of teams.’ These meetings typically coordinate efforts of teams that have no common ground. For example, all the IT delivery teams have a daily stand-up, as do the training teams, finance teams, pre-production teams, and so on, where representatives of each team gather to report on progress, plans, and impediments.

Parting Thoughts

A key success factor in Agile planning is that the project team is known at the start of the project and team members are 100% dedicated to the project. Agile cost planning is based on this in a top-down estimating approach, where costs can be calculated by taking the team members and their rate, and multiplying them by the number of iterations and then adding costs like overhead, materials, and third-party expenses.