Web www.albaspectrum.com

Popular articles

Experience gathered during large-scale implementation of Agile concepts in software development projects teaches us that the currently popular Agile software development methods (like Scrum ) do not scale to program, product and organization level without change. The fundamentals for changes to these methods are found in Lean principles, or: the future of Agile methods is found in its origins. This paper describes a planning framework that has been used successfully in large-scale Agile projects and investigates the impact of introducing this framework on three core Lean principles : Muri, Mura and Muda.

Planning in Large Scale Agile Projects

In Agile methods, loading a team with work is done through iteration planning. Due to the shortness of the iteration (typically one to six weeks) a plan reduces in importance and planning gains in importance. For small projects, it may be sufficient to plan only a single iteration at a time. The experienced disadvantage of iteration planning when applied to projects that run for more then a few iterations or with multiple teams is that the view of the longer term implications of iteration activities can be lost. In other words: the view of “the whole” is lost. A solution is to add planning levels to incorporate the current view of “the whole”.

In plan-driven and waterfall methodologies, this problem is overcome through a large upfront design, aiming to predict accurately how much work is involved in each project task. This leads to a large investment early in the project, when it is by no means certain that the designed functionality is actually the functionality desired by the product owner. An approach with multiple levels of planning has to avoid the reintroduction of the big design up front.

Planning activities for large-scale development efforts should rely on five levels:

• Product Vision
• Product Roadmap
• Release Plan
• Sprint Plan
• Daily Commitment


The certainty of undertaking activities addressed in each of the five levels increases, and therefore the amount of detail addressed (money invested), the number of people involved and the frequency can increase without running the risk of spending money on features that may not be built or may be built differently. Each of the five levels of planning addresses the fundamental planning principles: priorities, estimates and commitments.

Product Visioning - Level 1 The broadest picture that one can paint of the future is a vision of a product owner. In this vision she explains how an organization or product should look. She indicates what parts of the system need to change (priority) and what efforts can be used to achieve this goal (estimates and commitments).

Product Visioning - How To Possible structures for a visioning exercise are to create an elevator statement or a product vision box . The principle of both exercises is to create a statement that describes the future in terms of desired product features, target customers and key differentiators from previous or competitive products.

Geoffrey Moore uses the following structure in his elevator statement: “For (target customer) who (statement of the need) the (product name) is a (product category) that (product key benefit, compelling reason to buy). Unlike (primary competitive alternative), our product (final statement of primary differentiation).” The product vision describes a desired state that is 12 months or more in the future. Further planning (design) activities will detail the vision, and may divert from the vision because the future will bring us a changed perspective on the market, the product and the required efforts to make the vision reality.

Product Roadmap - Level 2 The era of large-scale projects that deliver results in years is behind us. Customers demand more frequent changes and typical time-to-market timeframes are 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 the fellow travelers, a product roadmap is created and communicated to fellow delivery people.

The goals for doing so 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 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


Product Roadmap - How To The creation of the roadmap is largely driven by the product owner (or product owner team). This stage of the program has limited influence of technology constraints. In a meeting or series of meetings, the roadmap will be drawn by the product owner. This can be quite literally, through a graphical representation of the releases, or more formally in a written document outlining the dates, contents and objectives of the foreseen releases.

Product Backlogs In anticipation of the next planning stage (release planning) a list of desired features needs to be built - the product backlog. In its simplest form, such a backlog is a table (spreadsheet) of product requirements, briefly described so a delivery team can provide estimates for the realization of each feature. Most importantly, the list has to be prioritized. The success of an Agile development project depends on the early delivery of the highest priority features. Since 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. Without a discussion of the features it will be hard for the delivery team to produce estimates that have an acceptable inaccuracy. Characteristics of a product backlog include:

• One product backlog for all teams (see the whole)
• Large to very large features (up to 20 'person days' to deliver a feature)
• Feature priority based on business priorities (discovered through market research)
• Technology features (sometimes called non-functional features, work required to make the product work in a desired way, e.g. the implementation of a certain DBMS in order to warrant a certain system performance) are limited to those that have a direct impact on the success of the product in the market.