1

PRE-WORK ASSIGNMENT

Excerpted from

Agile Almanac: Desk Reference

and

PM Field Guide

John G. Stenbeck, PMP®, PMI-ACP®, CSM, CSP

First Edition

La Mesa, CA

2

Agile Almanac: Desk Reference

and PM Field Guide

John G. Stenbeck, PMP®, PMI-ACP®, CSM, CSP

Published by:

GR8PM, Inc. 7918 El Cajon Blvd. #N-326 La Mesa, CA 91942 USA

(619) 890-5807 custserv@gr8pm.com; http://www.gr8pm.com/

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage and retrieval system without written permission by the author, except for the inclusion of brief quotations in a review. Copyright© 2013 by GR8PM, Inc. 1st edition. Printed in the United State of America. ISBN Edition: 978-0-9846693-2-5 This book includes material based on the Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc. 2012.” The book also contains many references to other registered terms such as PMP®, PgMP®, CAPM®, PMI-SP®, PMI-RMP®, or PMI-ACP®, which are registered marks of the Project Management Institute, Inc. This book expresses the views and opinions of its authors. The information contained in this book is provided without any express, statutory, or implied warranties. The authors, GR8PM, Inc., its resellers, and distributors disclaim any liable for any damages caused or alleged to be caused either directly or indirectly by this book.

3

Contents Chapter 1: About Enterprise-Agile ..................................................................................... 4  

Is Agile Really Needed? ................................................................................................. 4  Agile Value Proposition … in a Nutshell! ...................................................................... 5  Should You Pursue the PMI-ACP®? ............................................................................... 6  Market Share Information and Implications ................................................................... 7  About the Author ............................................................................................................ 8  

Crossword Puzzle ...................................................................................................... 10  Word Search .............................................................................................................. 11  Crossword Puzzle - Answer ...................................................................................... 12  Word Search .............................................................................................................. 13  

Chapter 2: Enterprise Agile and Blue Sky ........................................................................ 14  Chapter Highlights ........................................................................................................ 14  Agile-Enterprise Model ................................................................................................ 14  

Beginning With Market Development ...................................................................... 15  Scheduling Portfolios and Programs ......................................................................... 17  Employing Feature Stories for Scheduling ............................................................... 17  Relating Stories to the PMBOK® Guide ................................................................... 19  Understanding the Cone of Uncertainty ................................................................... 20  Creating Affinity Estimates ...................................................................................... 23  Building The Story Map ........................................................................................... 25  Defining Logic Networks ......................................................................................... 27  Analyzing Critical Paths ........................................................................................... 29  Reporting With Earned Value Management ............................................................. 32  

Chapter Close-out ......................................................................................................... 34  Chapter Close-Out ........................................................................................................ 35  

Crossword Puzzle ...................................................................................................... 35  Word Search .............................................................................................................. 36  Answers – Crossword Puzzle .................................................................................... 37  Answers – Word Search ............................................................................................ 38  

4

Chapter 1: About Enterprise-Agile

Is Agile Really Needed? Even though there is an early precursor of agile in the concept of rolling wave planning, the last major tool recognized in the Project Management Institute’s "A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Second Edition was the Critical Chain1 in 1997. That fact raises the first question we should ask, “What has changed since then?” Consider the following:

• Google launched in September, 1998 • The iPod was unveiled in October, 2001 • The BlackBerry “smartphone” was released in January, 2002 • NASA’s Phoenix lander extracted Martian ice in June, 2007 • The iPad was introduced in April, 2010

Interestingly, the Apple iPad provides a “classic case study” in Agile Project Management. In Lean and agile terminology, it was a full function device that included the minimum marketable feature set, yet it was not a full feature tablet PC. Because it was focused on what the customer wanted, it sold 3 million devices in 80 days and almost 15 million devices in the 8 months of 2010, taking 75 percent market share of tablet PCs by the end of the year. That meant that it sold more units than all other tablet PCs combined. The success of the iPad speaks eloquently to the success that agile enables. It also challenges organizational leaders who may feel an expectation for them to produce achievements like Steve Jobs2. PMI even seems to have acknowledged the increased demands and complexity of the project management universe. They moved beyond the long-cherished Iron Triangle – time, cost, scope – that was a part of every edition of the PMBOK® Guide through the Third Edition. With the release of the PMBOK® Guide, Fourth Edition, PMI took the traditional view of time, cost, scope, and added quality, risk, and customer satisfaction. The triangle became a hexagon in order to express increased complexity that project managers now face in the everyday world. Soon project managers around the world will be speaking about the “Hell-of-a-Hexagon” that replaced the “Iron Triangle.” (See Figure 1.1)

5

There is an abundance of additional evidence that points to the added complexity faced by project managers. Consider the high project failure rates documented over the last couple of decades by the Standish Group in the aptly named CHAOS Reports3. Or consider the report from Standish that proved only 20% of the features being delivered to users are in the “Always” or “Often Used” categories, while only 16% are “Sometimes Used,” and a full 64% fall into the “Rarely” and “Never Used” categories.

Agile Value Proposition … in a Nutshell! The playing field where human communities compete, from companies to nations, requires innovation and agility to create or maintain any competitive economic advantage. That sustainable advantage comes from systematic innovation. A strong correlation of that fact can be seen for industries from consumer electronics and pharmaceuticals to telecommunications. A mild correlation can also be seen for industries from healthcare and insurance to retail/wholesale. So whether communities thrive, survive, or fail is directly correlated to their ability to be agile and innovative. That core driver is behind the ever-increasing demand for Agile Project Managers. That is also the agile value proposition… in a nutshell! Stated another way, projects allow organizations to operationalize their innovative strategic vision. Executing those projects using the correct project management framework insures those projects maximize the positive impact of the assets and people deployed to deliver them. To accomplish this, professional project managers are increasingly being tasked by their organizations to synthesize the best practices of traditional and agile frameworks into an approach that is tailored to the environmental demands facing them.

6

Without a solid base of Agile Project Management knowledge it is impossible for a project manager to fulfill that responsibility effectively. Evidence strongly suggests that the future of project management is running hybrid projects. Tomorrow’s professional project manager cannot be effective without the ability to run hybrid projects. So, in a nutshell, the Agile Project Management value proposition is the ability to manage hybrid projects because you have an understanding of both traditional and agile frameworks!

Should You Pursue the PMI-ACP®? Market share data, discussed below, show that significant challenges may emerge for organizations, such as the Scrum Alliance, who advocate for training in a single framework. It also shows that it may be a significant boon to organizations, such as PMI®, that advocate for training in a multiple frameworks. So acquiring the PMI-ACP® certification will likely provide many career opportunities. As organizations pursue competitive advantage by leveraging project management to deliver innovation, it will translate into projects that have the “WOW!” factor. Being a PMI-ACP® could give you the chance to lead dream teams on projects of a lifetime. Additionally, if you feel like your job or your future is at risk, having the PMI-ACP® could keep you from getting passed over instead of promoted, at the next opportunity. Using this book helps you unlock the potential of the PMI-ACP® because it is more than just an exam preparation book. It is a Desk Reference and a PM Field Guide. It serves as a handy source of “how to” knowledge and best practices as you lead your teams after

7

you receive your PMI-ACP® certification. It can help you unlock a leadership role in moving your organization to the next level of agility and competitive advantage! This book will benefit anyone using or wanting to use Agile Project Management methods. It is good for people who are familiar with basic agile concepts as well as those who are not. This book is for:

• Program Managers and Certified Scrum Professionals

• Project Managers and Certified Scrum Masters

• Business Analysts and Product Owners

• Project Team Members – Engineers, Analysts, Developers, and Testers

• Customers and Managers

• Partners, Vendors, and Contractors

• College and University Instructors

Market Share Information and Implications This book was also guided by the usage, or market share, data gleaned from the Annual State of Agile Development surveys funded by VersionOne, Inc., as analyzed and summarized by Analysis.Net Research, an independent survey consultancy.

Figure 1.2 – 6th Annual State of Agile Development Survey Results4

8

The sixth annual survey was conducted during 2011 and polled individuals from a variety of channels within the software development industry. The data included a total of 6,042 responses. It showed that Scrum enjoyed major, although shrinking, market share of 52% while Scrum/XP hybrids held 14% and custom hybrids had 8%. Interestingly respondents selecting “Don’t Know” were 8% while Kanban and Scrumban each had 3%. The final group of “Many Others,” each with 2% or less, totaled 11%. Based on years of studying the data, GR8PM has made the following observations:

• 2011 was the first year when Scrum’s market share shrank. • The 8% of respondents who indicated “Don’t Know” would seem to imply that

their organizations are using a customized, or in our lexicon “hybrid”, choice. We have observed that in environments where a “standard” has been deployed, they tend to publish the name and practices of that standard.

• Hybrids emerged as a major player with a combined market share of 31% (14 + 9 + 8).

• Market consolidation started to show as “Many Others” shrank to 11% (a reduction of 35% ((17-11)/17)).

The change of hybrid market share from 2010 (17%) to 2011 (31%) was 82% ((31-17)/17) has major implications. GR8PM has been saying that this would be the direction the marketplace would choose because the desire for results supersedes allegiance to any given framework. We believe it is a leading indicator that hybrid has reached a tipping point. We believe that organizational demand for results will continue to drive professional project managers to customize the practices they employ to optimize outcomes. This may cause significant challenges for organizations, such as the Scrum Alliance, who advocate for training in a single framework. It may also prove to be a significant boon to organizations, such as PMI®, that advocate for training in a multiple frameworks. Another interesting leading indicator is the emergence of Kanban and Scrumban with 3% market share each. In 2010 they had no market share and in one year have emerged with a combined 6% share. That aligns with GR8PM’s previously stated opinions that as organizations mature in their usage of iteration-driven frameworks, such as Scrum and XP, they will be able to implement continuous flow approaches like Kanban. Crossing the threshold to iteration-less solution development approaches, like Kanban, can fuel significant competitive advantage that the marketplace will pursue. Doing so is not possible without first achieving the organizational growth that attends implementing other forms of agile development. But as the number of organizations using APM grows it will create a pipeline of candidates with the potential to implement Kanban-type approaches.

About the Author John G. Stenbeck, PMP, PMI-ACP, CSM, CSP, is a Principal at GR8PM, Inc., with a combined background in information technology (IT), accounting, and operations. He

9

has the ability to manage large, complex projects to success where others have failed. John has extensive experience implementing enterprise resource planning (ERP) systems at firms in the aerospace, shipbuilding, and construction industries. John is an Adjunct Instructor for the University of California – San Diego's School of Extended Studies, where he teaches project management in the Systems Engineering Certificate program. As a trainer, he has taught numerous public and corporate on-site programs to over 7,500 students. John helps technical professionals in the high technology, aerospace, defense, financial services, and bio-pharmaceutical industries master project management and executive leadership skills. Over the past fifteen years, he has coached, trained and managed projects for a host of companies including Booz Allen Hamilton, Inc. – Defense Information Technologies Group, McLean, VA; Delta Design – a division of COHU International, Poway, CA; Guinness Bass Import Company, Greenwich, CT; Hewlett-Packard Company, Palo Alto, CA; Lucent Technologies, Allentown, PA; Nike Corp., Beaverton, OR; Oracle Corp., Redwood Shores, CA; Qualcomm, Inc., San Diego, CA; Select Build, Inc. – a division of BMHC, Inc., Boise, ID; Simplex Solutions, Sunnyvale, CA; U.S. Army – Space and Terrestrial Communications Directorate, Fort Monmouth, NJ; U.S.D.A. – National Finance Center, New Orleans, LA; Visa – Smart Cards, Foster City, CA. John holds the Project Management Professional (PMP®) credential and the Agile Certified Practitioner (PMI-ACP®) certification from the Project Management Institute (PMI®). He is also certified by the Scrum Alliance as a Certified Scrum Master (CSM) and a Certified Scrum Professional (CSP). Additionally, he has an ITIL v.3 Foundations certification. John graduated from San Diego State University with a BS in Business Administration, with an emphasis in Accounting. John has also authored seven nationally delivered training programs. Chapter End Notes 1Goldratt, E. M. (1997). Critical chain. Great Barrington, MA: The North River Press. 2 Steven Paul "Steve" Jobs (February 24, 1955 – October 5, 2011) was a visionary widely recognized as a charismatic pioneer of the personal computer revolution. He was co-founder, chairman, and chief executive officer of Apple Inc. 3 See for example CHAOS 2009 Report Summary, Boston, MA, April 23, 2009, The Standish Group International, Inc. (www.standishgroup.com) 4 The sixth annual “State of Agile Development” survey was conducted between July 22 and November 1, 2011. Sponsored by VersionOne, the survey polled individuals from a variety of channels within the software development industry. The data was analyzed and prepared into a summary report by Analysis.Net Research. A total of 6,042 responses were received.

10

Crossword Puzzle

Hints: Across 2 PMI’s agile certification. 5 Iterative project management method. 6 Continuous flow agile framework. 8 The information economy has been replaced by? 10 Scrum Alliance certification. 12 The oldest project management method.

Down 1 Hybrid of Scrum and continuous flow frameworks. 3 Team management frameworks. 4 Written by 17 visionaries in Snowbird, UT. 7 Customize frameworks. 9 The PM body of knowledge 11 Organizational framework.

11

Word Search

Word Search - 12 Words to find: • AGILE • HYBRID • INNOVATION • KANBAN

• MACRO-DYNAMIC

• MANIFESTO • MICRO-DYNAMIC • PMBOK

• PMI-ACP • SCRUMBAN • SCRUMMASTER • TRADITIONAL

 

12

Crossword Puzzle - Answer

13

Word Search

 

14

Chapter 2: Enterprise Agile and Blue Sky

Chapter Highlights In this Chapter we will develop enterprise-level agile. This content is Blue Sky because it is not covered in any of the industry exams. But it remains important to those readers who are preparing for an exam because it provides a model or paradigm for “exercising” the other content. Doing so increases learning and retention and therefore assists in passing the exam. For the many users who are currently struggling with taking agile to the enterprise-level this may be the most vital content in the book. It recognizes that the biggest opportunities in APM today exist for professionals who can take a micro-dynamic, team management framework and scale it up to a macro-dynamic, organizational framework. Chapter 2 moves beyond micro-dynamic team-level practices and into the agile practices that drive and guide enterprise maturity at the multi-project, program, portfolio and enterprise levels. In particular it covers how to:

• Accelerate speed-to-market using agile Product Development processes • Deploy agile-aligned portfolio and program-level scheduling • Integrate architectural and engineering best practices with multi-project agile • Optimize agile estimating and risk management protocols • Deliver organizational control and reporting using Earned Value Management

Chapter 2 addresses the fact that every agile framework is missing two critical elements – sophisticated scheduling tools and accounting cost management. In Chapter 12 we will address accounting cost management using Earned Value Management (EVM) with a deep dive into the details.

Agile-Enterprise Model Enterprise-level APM actually begins before the first project begins. It begins with market development and product development because they drive competitive advantage. Many industries, including Aerospace and Defense, Automotive, Consumer and High Technology, Manufacturing, and Pharmaceuticals and Life Sciences attest to that simple truth. They used it to accelerate revenue, reduce costs, and improve product quality by shortening product lifecycles, reducing supply chain complexity, and satisfying ever-increasing customer demands. Today many organizations must deliver operational excellence across an extended enterprise product pipeline that includes vendor-partners. They must integrate outsourced providers and internal processes to create innovation based on decisions about their products throughout local, regional and global distribution networks. The driving variable in this environment is time-to-value. And it affects much more than just software, the heretofore-primary domain of APM. Companies as diverse as Bayer,

15

Flextronics, GE Medical Systems, Heinz, Johnson & Johnson, Lockheed Martin, McAfee, McDonald’s, Philips, Qualcomm, Siemens, and Tyco Healthcare, are using agile Product Development processes to drive positive business results. Speed-to-market and time-to-volume determine time-to-value, and success, in many markets. Agile product development transforms time into a competitive advantage when clearly communicated market development strategies and tactics enable teams to align with the enterprise product pipeline.

Beginning With Market Development

Because this is a book on APM and not market and product development, we are only going to use the simplified model shown in figure 2.1 to discuss the broad themes that form the backdrop of the macro-dynamic that enables APM. The Market / Product Development Matrix identifies four quadrants that must be evaluated as strategies and tactics are develop. They are:

• Quadrant 1, where the organization has an existing market and can best leverage incremental, sometimes described as continuous improvement, types of innovation to deliver the desired results.

16

• Quadrant 2, where the organization has an existing market but needs a disruptive type of innovation, perhaps because they are competing with much larger organizations, in order to deliver the desired results.

• Quadrant 3, where the market is new to the organization but can be accessed with incremental innovation to existing products.

• Quadrant 4, where the market is new, and promising, so the organization seeks to establish a presence and needs a disruptive type of innovation, perhaps because the potential market is unaware of its “need”.

In most cases achieving time-to-value, and success, requires eliminating barriers that cause latency in organizational action, creating and protect intellectual property which is the domain of APM. In quadrant number 1, agile projects should seek innovations that minimize the customer’s cost for their total solution experience. Often this entails identifying ways to innovate the delivery channel in the existing business model. The more complicated and cumbersome the delivery channel is, the higher the customer’s total solution cost because of the value of their time and frustration. In quadrant number 2, agile projects should seek disruptive innovations to out-compete larger organizations. Because agile product development can be implemented using APM it is possible to employ several teams, or one team testing several spikes, to identify the most promising innovations. Promising innovations occur at the intersection of novel concepts and probability-managed development methods, a core APM competency. In quadrant number 3, agile projects should seek innovations that extend existing products in ways that offer a unique improvement to the customer’s total solution experience and cost. Again this can be accomplished using APM to employ several teams, or one team testing several spikes, to identify the most promising innovations. In quadrant number 4, because the market is new and promising it is imperative that agile projects deliver innovations that unlock the customer’s awareness of a totally new solution experience. This is precisely what Apple’s iPad did for consumers raised on the web and frustrated with the ineptitude of tablet PCs. The unifying theme from the Market perspective is for APM teams to focus on a “target” competitors can’t hit. The unifying differentiator for the Strategy perspective is that incremental innovation delivers more “desirability” while disruptive innovation hits a target that competitors haven’t even seen. Innovation is the engine of growth when it is delivered without compromising quality or customer flexibility. APM means distributed and remote product design teams can collaborate, leverage insight, fuel creativity, and enhance product designs. The result is continuously shortened cycle times from concept to customer value because of leveraging discovery and learning and translating it into intellectual property.

17

The combination of executive-level vision and fast, proactive product development integrated across market opportunities creates enviable competitive advantage. By streamlining the product development process and integrating it to the market strategy APM rapidly produces profitable products and growing market share. In order to access these benefits proper portfolio and program planning must precede APM. APM can only be optimized when it is imbedded within enterprise-level strategically rationalized decision practices that support the capabilities of agile teams to deliver better operational results.

Scheduling Portfolios and Programs To integrate multi-project architecture and engineering, the portfolio- and program-level planning processes must be expressed as a Roadmap. That process begins with first defining the key features of the various products or services being offered in the organization’s market development plan. Those defining the key features are called the minimal marketable features (MMF), for each component or product, in the program or portfolio. Definition: The MMF is comprised of the smallest set of features that provide the level of functionality required to deliver satisfactory customer value and create a competitive distinction. To begin, senior management creates a central feature list, which is a rough sketch or superset, of the critical functionality that represents the MMF. It is used as an input for planning the Roadmap and Releases. It represents the vision for current product development as well as the potential of what could be developed, perhaps, over several releases. Note that it is not necessary to wait until all features are defined before starting development of the initial product functionality. After the central feature list is created, each feature will need to be documented as a Feature Story either by senior management, or more likely there designees, as part of the planning process.

Employing Feature Stories for Scheduling Feature Stories are documented by writing down the goal, the specific piece or component of business functionality that the user needs in order to perceive value. The Feature must be expressed with enough granularity so that the approximate effort of developing that Feature can be expressed at a rough order of magnitude (ROM) level. Defining, even roughly, the approximate effort of a Feature Story enables initial prioritizing and reduces the likelihood of radical indiscriminate scope reductions later. There are a variety of opinions about exactly what estimating at a ROM level means. Our preference is that ROM means estimates that may be under the actual outcome by as much as 50% or over the actual outcome by as much as 25%5. Experience has shown that estimates are asymmetrically distributed, with the probability of under-estimating

18

exceeding the probability of over-estimating, and that estimates become less accurate as they forecast events that are farther out in the future. Because Feature Stories are long-range forecasts, they can only be estimated at the ROM level, but they are useless if they cannot be estimated. Experience has also shown that many times a Feature will appear necessary or valuable when first conceived, but often gets abandoned when it is supplanted by a better, or simply different, alternative as the project progresses and additional customer discovery and learning occurs. Therefore, developing Feature Stories is guided by the principle of the last responsible moment. That means that the team documents the details of a Feature Story when they decompose it into User Stories. At that point in time the probability of actual development is high enough to justify spending the resources on detailed planning. Feature Stories (and User Stories) are a deceptively simple way of integrating purpose-driven customer conversations with drawings, prototypes, and small segments of code that unlock the powerful human genius imbedded in experiencing tangible samples that relate to the whole solution. Those kinds of conversations allow customers to evaluate small steps of progress and provide “actionable insight” about the optimal way for the project to be successful. The power of this approach becomes a “blinding flash of the obvious” when you remember that written words, especially in those ever-popular emails, are very tenuous expressions of the unavoidably complex content of most projects. Because, as the saying goes, “The greatest myth about communication is…that it has happened”, vigilance is required to prevent misinterpretation. Frequent conversations between the customer, users, and the team create a tremendously powerful antidote to this common problem. Feature Stories prevent overlooking or forgetting to discuss important functionality at the appropriate time and so they support robust estimating and planning. To succeed, a project must take information from a variety of customers, users, business analysts, technical experts and the team and understand and integrate it. And of course, learning and integration take place while the team is trying to properly allocate resources, juggle trade-offs between quality, other current features, and partially described expected future features. When that environment is visualized it becomes clear why it is impossible to perfectly predict the path of development for the best solution. In such an unpredictable environment the most cogent approach is to make decisions based on the reliability of the information available. In APM decisions are made at the optimal point when two factors intersect. Decisions are made at the intersection of “the last responsible moment” and “the best available information.” Decisions are made at “the last responsible moment” which means they are not made prematurely because important information might emerge. That information constitutes “the best available information” in part because it is as complete as possible. Making decisions before that point in time means the best available information is not available. Making them after

19

that point in time means risks and problems that could have been avoided will instead be induced. Many things change – not the least of which is the customer’s understanding of their need and the best solution – as successive iterations produce new learning. That is why we use Feature Stories for planning and need User Stories for development. The two types of Stories facilitate decision making at the intersection of “the last responsible moment” and “the best available information.” Stories are a tool or device or technique to capture a description of important functionality considered valuable to the customer or user of the solution being developed. Stories are a multifaceted device with tangible and intangible aspects. They are composed of a written piece, the tangible “Card”, that represents customer requirements and is used in the planning process; an intangible promise (or commitment) to have conversations with the customer or user or technical experts, as and when needed, to identify details of the story at the appropriate granularity to enable planning and development of the solution, and a written, tangible collection of tests that will demonstrate when a story is complete. The key is that Stories describe customer value, as Feature Stories or User Stories, and facilitate planning and information management.

Relating Stories to the PMBOK® Guide The PMBOK® Guide defines a specific taxonomy, or arbitrary logical device, called a Work Breakdown Structure (WBS) for organizing information with five levels. The highest level is Objective, followed in descending order by Phase, Work Package, Activity and Task. The higher levels have ideas expressed in broader, less specific information while the lower levels have the same ideas expressed in greater detail. The WBS is a very useful tool because of the immense amount of information that must be collected and managed as part of any project. APM, by contrast, uses a taxonomy called a Feature Breakdown Structure (FBS), for organizing information. However, because APM has not been codified into a standard there are a number of naming conventions for the various levels. One of the most common naming conventions identifies the highest level as Product, followed in descending order by Theme, Epic, Story and Task. The higher levels have broader, less specific information while the lower levels have greater detail. The FBS is a very useful tool for the same reason as the WBS. The WBS and the FBS share several aspects in common. First the naming conventions are figurative in the sense that they describe what they contain in general terms relative to the other levels. There is not a precise definition of the difference between an Activity and a Task, or an Activity and a Work Package. Likewise there is not a precise differentiation between Story and Task or Story and Epic. The higher-level term, in both schemes, is bigger while the lower-level term is smaller. The purpose of both the WBS and FBS is to facilitate managing project information not to impose a rigid set of size criteria.

20

A common cause of confusion is the use of the term User Story to describe a Card. Based on the size of the idea, and the amount of detail present or absent, the Card can be a Feature Story or a User Story. Cards can be classified as a Theme, Epic, Story or Task yet it is not uncommon to refer to all of them as a “story”. This confusion can be avoided by using more accurate terminology when expressing yourself or by asking clarifying questions when others are expressing themselves. Likewise, a common cause of frustration, especially for those new to APM, is the fact that Stories do not document deep, specific detail like the specifications used in Traditional project management. Rather than writing all the details in the story, the development team and the customer have promised to have a conversation about the details at the point when those details become important. The point of frustration occurs because neither the team nor the customer can point to the card months later and use it to avoid ownership of a problem by saying something like, “I wrote that disclaimer right here” or “I made that part of the spec right here”. And many participants in projects have learned how to “use the details” for coverage when a problem comes storming along. Lastly, as stated above, Stories include a written, tangible collection of tests. Those tests demonstrate in measurable terms the agreement between the customer and the team about a story’s completion and acceptance. This facet of User Stories meets the vital need to clearly understand the customer’s expectations. By recording acceptance tests on the card the User Story captures those expectations in a measurable form. The tests are written reminders about the story expectations and help clarify for the team when they are done. The Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fourth Edition, Project Management Institute, Inc. 2008” describes a project as, “A temporary group activity designed to produce a unique product, service or result.” That definition presupposes decisions have been made about what unique problem the product, service or result will solve. It implies what the solution will deliver. Agile Project Management, by way of contrast, presupposes that an accurate and exacting knowledge of the problem and its solution do not exist – actually cannot exist – in advance. Agile assumes that an inescapable part of the development process is discovery and learning. Discovery occurs as the project moves through the Cone of Uncertainty encountering the unknown and the unexpected. Discovery is shared with the Customer, who is most qualified to decipher and interpret the meaning of the discoveries. Then the customer and team translate the discoveries into learning that provides proper perspective on the impact on priorities. Using that learning the team acts as a trusted advisor, presents options to the Customer, translates those options as potential Features, and negotiates when and how to implement those Features.

Understanding the Cone of Uncertainty APM embraces the idea of a Cone of Uncertainty because complex problems cannot be fully defined in advance. APM uses a scientifically validated empirical process control

21

approach – transparency, inspection, and adaptation – to focus the team on quickly delivering results that move through the cone of uncertainty towards a solution in the midst of emerging requirements.

Moving from agile as a micro-dynamic, team management framework and scaling it up to a macro-dynamic, organizational framework is a bit like moving from playing checkers to playing chess. Chess is clearly more complicated than checkers and offers more challenges and rewards. In higher levels of chess competition, there are three general objectives during the Opening. The first objective is to achieve better positioning, if you are playing as White, or to neutralize White, if you are playing as Black. The second objective is to create dynamic, competitive imbalances that favor your side and align with strategic Mid-Game choices. You may seek to improve your advantage or to blunt the competitor’s advantage. Finally a third objective is to lure the opponent into positions where you have an advantage or feel more comfortable. The opening moves in APM are intended to move the project through the areas of least clarity and greatest flexibility in a way that aligns the probability of success and the strategic vision of the organization. The Mid-Game, or Middle game, in chess follows the Opening and blends into the End Game. The three major objectives in the Mid-Game are king safety, force, and mobility.

22

King safety can be compared to strategic alignment because a well-executed attack on the king can render other advantages irrelevant much like the iPad rendered tablet PCs irrelevant. Force, often referred to as Material, is similar to market share or market position in the real world. If all other factors are equal then material advantage will favor the larger competitor because they have the resources to gain more material and create a decisive advantage. Before the dawn of the Internet and options like the Amazon marketplace, material advantage was much more insurmountable. The new electronic marketplace options have amplified mobility, expressed as creativity and flexibility in the real world, because the scope of actions and segments to specialize in has become virtually unlimited. Because mobility must be managed at the enterprise-level, the demand for agile project managers who can lead efforts to scale agile to the enterprise has reached a fever pitch in the marketplace. Interestingly, the chess game analogy can be overlaid on the S-curve that is familiar to traditional project managers all over the world (see Figure 2.3) with many of the same conclusions. It also draws out another conclusion shared in common with the cone of uncertainty. The later in the solution development cycle a change is made the more risky and expensive it is to implement.

23

The insight to be recognized and leveraged is that there are significant advantages to be gained by having a planning process that properly processes the discoveries and learning available in the early part of the cycle to create advantages in the later part of the cycle. The iterative planning process embraced by APM is exactly that type of process. The iterative process begins with developing ROM estimates, or what APM refers to as Sizing, for each of the Feature Stories. APM uses a tool or process called Affinity Estimating to do this quickly and cost effectively.

Creating Affinity Estimates Lowell Lindstrom first presented Affinity Estimating in 2008 at a Scrum Trainer’s Retreat. It is a technique for sizing a large number of Stories quickly. It has proven useful for portfolio and program planning because it is designed to process a large batch of estimates quickly. Initially it was used at the beginning of projects with a large initial backlog of more than 25 or 30 User Stories because it quickly facilitated adequate planning. We have used it with portfolios or programs that have as many as 200 to 300 Feature Stories and produced a Roadmap in as little as three or four hours. Since 2008, as you might imagine, Affinity Estimating has been adapted and refined through a host of experiments and applications. We like it because it is an approach that aligns well with the agile principle of low-tech, high-touch tools. Since Roadmaps are critical and high-level they are usually done with a collocated team of executives making Affinity Estimating a great fit. However, as you move down into the trenches with distributed and remote teams doing it electronically is a bit of a challenge. We will describe how an executive team would use our preferred version of this technique to create a portfolio or program Roadmap. Definition: Affinity Estimating is a technique for estimating a large number of Stories, in a quick cost-effective way, which supports the planning and decision-making process. To begin senior management or their designees must create the individual Feature Stories. The process for doing so is the same as the one for creating User Stories, which is describe in detailed, later in the book. There are two significant differences between the stories. First, for Feature Stories the scale or granularity is higher or coarser. Second, the Feature Stories may contain notes about test or acceptance criteria but they are completely optional. For User Stories they are definitely required. Once the Feature Stories are written, the customer and team gather and one of them defines a scale, typically from extra small (XS) to extra large (XL)6 and also a “Parking Lot” on a large white board or wall. Then a first pass guess at the sizes of each Feature Story is created by posting them on the wall in groups or columns below the XS to XL scale, or in the parking lot if they are to vague to be sized. Before the creation of the first pass occurs, the following simple instructions are reviewed:

• Each Team Member will be given an equivalent stack of User Stories.

24

• Team Members will size each Story, relative to other stories, based on the effort required to delivery it, considering the acceptance criteria or tests if any are provided.

• Vertically stack any Stories of the same size within columns or groups. • Each Team Member will work in silence, except to request access to the board. • Stories that are too vague to size should be placed in the parking lot. • Questionable stories will be clarified, with acceptance criteria if needed, after the

first pass is completed. The silent sizing of the stories, and parking of uncertain ones, should take between 20 and 30 minutes. If a larger number of participants are involved, which is not recommended, it may be beneficial to have them work in smaller groups at the board. After the first pass has been created, the Team begins the revision phase. Team Members review – still silently – and move them to a different column or group if they believe the current placement is incorrect. The first time a story is moved the Team Member notes the change by writing a small diagonal line in the bottom right corner of the card. If another Team Member decides the sizing is incorrect they moved it and scribe a second diagonal line that crosses the first line creating an “X”. If any Team Member decides that the story must be moved yet again, it is obvious that the story is too vague and it is moved to the parking lot. The final phase of Affinity Estimating occurs when the team engages in dialogue about vague or misunderstood stories. At this point it is common for design discussions to intersect with senior management clarifications about the market development plan so that the needed understanding is achieved. An important risk that needs to be avoided at this point is the risk of senior management disrespecting the Team’s view of the size. Care needs to be exercised when communicating why the size does not align with expectations. Often additional acceptance criteria and tests will be identified and added to stories so that expectations are clarified and brought into alignment. This phase may take several hours, or slightly more, to complete. It is very important and should not be rushed unduly. The final Affinity Estimating result would look something like this.

25

Building The Story Map The Affinity Board that was just created contains two things. First, the board contains all of the Stories that are currently understood to be part of the market and product development plan. Second, the board contains the relative size of each story. Both pieces of information are critical predecessors, or inputs, to building the Story Map that represents the best way to approach solution development and delivery. To avoid confusion it is important to point out that a Story Map is not a Story Board. A Story Board is used to manage a specific Iteration. A Story Map is used to plan the content of the Roadmap in a way that aligns them with the goals of a market and product development plan. A Story Map can also be used to plan Releases, by decomposing stories into greater granularity, so they align with the Roadmap. In this case, Release is something of a synonym for a Program and Roadmap is a synonym for a Portfolio. In order to find the best approach for developing the various solutions it now becomes imperative to arrange the stories across a time scale where the most important components get developed first and the remaining components get developed in descending order of priority. Once that is done the Story Map can also be used to determine how fast solution development can be expected to proceed and set a baseline schedule. We will address each of these, but since it always helps to begin with a view of the end result in mind, here’s what the final outcome is expected to look like:

26

To accurately understand the illustration above there are a couple of assumptions that need to be explained. First, the highest priority items are at the top of each column. Second, sometimes due to architectural or engineering considerations, some lower priority items get included in prior solutions. Third, the Forecast Velocity for a Release was set 45 person-weeks of effort for a team, so that was defined as the planning limit. Lastly the Team defined Extra Small (XS) stories as requiring 1 week to complete, while Small (S) stories required 2 weeks, Medium (M) stories required 3 weeks, Large (L) stories required 5 weeks, and Extra Large (XL) stories required 8 weeks. The analysis behind the grouping activity, represented by the lines drawn around stories, focused on identifying coherent groups of features that align with business functionality and user activities. Each group, or solution or product, included stories that are linked in complete threads of necessary features that customers’ value. Using customer discovery and learning during the Review meetings will generate “actionable insight” about the optimal way to proceed through the cone of uncertainty. That feedback and insight helps the team determine how to best integrate the completed threads of prior iterations with the threads of subsequent iterations until enough stories have been completed and a release, or product launch, can occur. A best practice that is often overlooked is to socialize the initial Roadmap broadly for feedback and comments. This can uncover great risks and spectacular opportunities before a huge financial stake has been made. Few things bring as much value and are more overlooked!

27

In order to really do agile at the enterprise level it is necessary to use a couple of traditional tools in order to create plans that can handle the complexity inherent in programs and portfolios. That means that enterprise-level agile is really a hybrid. The first of those tools is the Logic Network.

Defining Logic Networks To begin there is an important and interesting question that must be asked for clarity’s sake. That question is, “What is the difference between planning and scheduling?” At its most central and fundamental core, planning decides what must be done while scheduling decides when to do it! First in the sequence is making sure that every important element of the portfolio, program or project is identified and grouped by size in an affinity estimate. Second is the effort to leverage every opportunity to increase speed and flexibility while lowering risk by effectively integrating the execution of various projects. Project scheduling usually refers to two tools or disciplines. The first discipline is the Logic Network for defining the relationships between activities. The second discipline is the Critical Path Method of calculating and analyzing the time dimension of those relationships. These two disciplines provide insight into areas that are often vague and have a high probability of becoming problems without effective management. That insight can then be used to avoid obstacles and focus appropriate resources where they can help solution development stay on schedule. Schedule Creation Logic Networks are where portfolio, program, and project schedules are created. Developing one requires that the dependencies between stories be accurately identified. Those dependencies show what actions impact the development and delivery of a solution or product. The goal of a logic network is to create visibility and clarity about the inputs that could become impediments for subsequent stories. Creating the logic network allows, or maybe forces, the planning team to collaborate until a unified vision of execution emerges. Because it is a high-touch, low-tech method, it draws out the optimum level of contribution from each team member. Quite often it also reveals aspects of the interdependence of various team members and resources that weren’t apparent to everyone initially. Creating a logic network from a Roadmap Story Board is a three-step process. First, it requires arranging the stories within a Release according to predecessor-successor relationships. Next inter-Release predecessor-successor relationships are defined by drawing arrows between the stories if different Releases. Finally the team evaluates the logic of the network to create visibility and clarity about any conflicts that may exist. It is worth noting that there are various types of arrows used to diagram dependencies. There are four types of dependencies – One-to-One, One-to-Many, Many-to-One, and Many-to-Many – and they are each diagrammed differently. They are:

28

One-to-One means that one, and only one, story must be completed before the next story can begin. For example, drywall must be installed before it can be painted (in standard residential construction) but once it is installed painting may begin without the completion of any other activity. One-to-Many means that one, and only one, story must be completed before multiple follow-on stories can begin. For instance, plans must be approved before either permits can be obtained or site preparation can be started (in residential construction). Many-to-One means that each and every one of two or more stories must be completed before a subsequent story can begin. As an example, the completion of both the engineering design and the manufacturing design are required before production is started in many industries.

Many-to-Many means that each and every one of two or more stories must be completed before multiple subsequent stories can begin. As an example, many times both software code and copyright registration must receive final approval before either marketing or production is started. You will note that in one-to-one relationships a single line passes between the stories. In one-to-many relationships a single line divides after it leaves the predecessor and moves towards the successor, indicating mutual dependence on the predecessor. In many-to-one relationships multiple lines merge after leaving the predecessors, and then connect with the successor, indicating its dependence on the completion of all prior stories. Finally, in many-to-many relationships multiple lines merge after leaving the predecessors, and then re-divide as they connect with the successors, indicating mutual dependence on the completion of all predecessors. Ultimately the purpose of the logic network is to allow the team to anticipate problems before they happen, eliminate their causes or mitigate their impact, and decrease the need for crisis management. In fact, a properly constructed network will enable various agile teams to forecast the need for inter-team adjustments while risks are still in the future.

29

To do so the team must understand whether inter-Release dependencies are “hard” logic or “soft” logic. Hard logic means that due to the relationship between a given story and subsequent stories, it must precede them. For example, constructing the hull of a ship must occur before building the decks. Soft logic, on the other hand, means that the order of execution may change if needed. For example, when building a home, installing the kitchen cabinets may or may not happen before installing the bathroom vanities. By reviewing the logic network that presents planned work execution it is possible to evaluate whether dependencies are shown correctly. It is also possible to decide whether execution is bound by hard logic or soft logic. This creates an opportunity to look for ways to increase speed or reduce risk by changing the order of story execution. However, in order to be truly professional we need to do more than use intuition or “gut feel” to evaluate the logic network. We need to apply a tool that quantifies and analyzes it so that time critical elements of the schedule are identified.

Analyzing Critical Paths Applying the Critical Path Method (CPM) to the Roadmap logic network processes information about story relationships in a way that creates visibility into time constraints that will impact the way a program or portfolio integrates with a market or product development plan. Understanding and managing the critical path allows teams to direct resources to help development stay on schedule, while balancing the cost and value of unavoidable trade-offs. It also allows development to occur in a manner that optimizes the benefits enjoyed at the enterprise level. Properly balancing the application of resources not only enhances the returns enjoyed by the enterprise but may actually be vital to its long-run growth and profitability requirements. When a Roadmap logic network is created there is usually development happening simultaneously on several different products. Development of various stories occurs on the “paths” of the logic network within each Release. But there are also paths running both sequentially and in parallel between the Releases. CPM helps us ascertain two vital pieces of knowledge so they can be communicated to key stakeholders. First, it identifies which stories can cause the development schedule to slip. Second, it identifies which stories can improve the total performance of the development effort if resources are supplied or dependencies are changed. In order to accurately understand and communicate either piece of information it is imperative to use two terms – critical path and float – correctly. In CPM the term critical path refers only to time. It neither measures nor implies the importance of any story. Both important and mundane stories can be on the critical path. What is identified and emphasized is the one path in the logic network where the duration of the stories combined with their dependencies, will take the longest to complete. Consequently, every story on that path is time critical. Any delay in completing those stories will directly impact when development is completed.

30

CPM uses the concept of float to accomplish the job of identifying the critical path. Float is the time difference between when a story that is not on the critical path is scheduled for completion and the latest allowable time it can be completed without negatively impacting the finish of development. When the scheduled time of completion equals the latest allowable time, by definition float equals zero. Therefore, any slip in completing the story directly impacts the completion of development. When the scheduled time of completion is earlier than the latest allowable time, float is greater than zero, and any slip in completing the story that is less than or equal to the float will not negatively impact the completion of development. To reiterate and reinforce, among the various paths that represent work execution in the Roadmap logic network, one of the paths represents the shortest time in which the project can be accomplished. It is the critical path because if the duration of any story is under-estimated or there is a delay in beginning any story on this path, it will cause a delay in the completion of development. The duration and start date of every story on the critical path is time critical, regardless of whether the story is of high importance or mundane. Step-by-Step CPM As we build upon the Roadmap Story Board, the process of applying CPM occurs in five steps. First, convert the Logic Network to a CPM flowchart. Second, conduct a ‘Forward Pass’ calculation. Third, conduct a ‘Backward Pass’ calculation. Fourth, calculate Float. And, fifth, evaluate the Critical Path. Let’s look at each. Step 1 – Convert Logic Network to CPM Flowchart. To convert the logic network into a CPM flowchart each story must include required CPM diagramming information. The process begins by using the cards from the Roadmap Story Board. The card must include the Story Name and Duration from the Affinity Estimate written in the proper place, or cell. The definitions of the first two cells to be completed are: Story Name is the unique title of the story. It facilitates recognition of the feature being developed. Duration is the Affinity Estimate of the effort required to complete the story expressed in a consistent unit-of-measure (such as hours, days, weeks, or months). The definitions of the next two cells to be completed, as part of the Forward Pass calculation, are:

31

Early Start Date is the earliest date on which all preceding stories will be complete thereby allowing work to begin on the designated story. Early Finish Date is the earliest date when all work can be completed for the designated story. Step 2 – Conduct a ‘Forward Pass’ calculation. Calculating the critical path begins with a sequential “forward pass” through the entire network. The forward pass calculation applies the equation Early Start plus Duration equals Early Finish (ES + D = EF) through the entire network from the start to the finish. By definition, the early start value of the very first story is zero. For one-to-one dependencies, the early finish value for each predecessor is carried forward as the early start value of the successor. For one-to-many dependencies, the early finish value of the predecessor is carried forward as the early start value for all successors. For many-to-one and many-to-many dependencies, the largest early finish value from amongst all predecessors is carried forward as the early start value for all successors. The result of each calculation is recorded in the appropriate cell. The definitions of the next two cells to be completed, as part of the Backward Pass calculation, are: Late Start Date is the latest date upon which work can begin on the designated story without delaying the completion of development. Late Finish Date is the latest date upon which work on the designated story can be completed without delaying the completion of development. Step 3 – Conduct a ‘Backward Pass’ calculation. The next calculation in CPM is the reverse-sequential “backward pass” through the entire network. The backward pass calculation applies the equation Late Finish minus Duration equals Late Start (LF - D = LS) through the entire network, in reverse order, from the finish to the start. By definition, the early finish value for the last story is assigned or copied as the late finish value of the same story. For one-to-one dependencies, the late finish value of the predecessor is carried back from the late start value of the successor. For one-to-many dependencies, the late finish value for all predecessors is carried back from the late start value of the successor. For many-to-many and many-to-one dependencies, the late finish value for all predecessors is carried back from the smallest late start value of the successors.

32

Again, the result of each calculation is recorded in the appropriate cell. The entire backward pass calculation should be completed before the float calculation is started. The definition of the final cell to be completed, as part of the Float calculation, is: Float is the number of time periods the early start can be delayed, or duration can be extended, without delaying the completion of development. Step 4 – Calculate Float. The last calculation establishes the Float. The calculation is Late Finish minus Early Finish equals Float (LF - EF = F). The calculation for each story is independent of every other story. Therefore, the float calculations may be done sequentially or in parallel. The result of each calculation is recorded in the appropriate cell. Step 5 – Highlight the Critical Path. Once the calculations have been completed, the Critical Path is the path of stories where float equals zero. The normal convention is to highlight the arrows connecting the activities with a red marker. Again, this path is the critical path because any overrun in duration, or delay in beginning, any story on this path will delay the completion of development. Schedule Management Schedule management is where experience and judgment combine with quantified observations to find opportunities and identify risks. Doing the analysis and making any needed changes so the schedule is realistic is the first part of schedule management. Responding to variances in actual work execution and finding ways to maintain development momentum is the second part. Revising the Roadmap, or baseline schedule, when change requires it is the third part. With a baseline schedule created and managed accurate reporting becomes possible.

Reporting With Earned Value Management Earned Value Management (EVM) will be discussed in great depth in a later Chapter but here an explanation of why it is so important to enterprise-level agile will be provided. One question that deserves to be addressed immediately is, “Why is EVM even necessary?” The answer is that agile frameworks do not articulate how to identify, track and manage costs. That means without EVM agile cannot analyze and evaluate Return on Investment (ROI) as part of the market and product development vision. It also means agile cannot meet a fundamental business need.

33

Because EVM is a program management tool that integrates the technical, cost, and schedule information, EVM may even prove to be the missing link that enables agile to fully function at the program and portfolio levels needed by the enterprise. Yet few things in project management – traditional or agile – are more abhorred than accounting control, in particular creating a cost baseline and measuring performance against it. But few things are more fundamental to project success than proper financial performance. That means that enterprise-level agile simply cannot exist without enough accounting control to effectively report on resource consumption and value creation. Once the Roadmap has been created, the forecast-cost per story can be established and a cost baseline created. The using development’s average velocity the Roadmap can be analyzed to determine if the probability of meeting the planned delivery dates is improving or deteriorating. Awareness of a deteriorating probability is a difficult message to have to communicate, but if it is done timely it strengthens relationship trust. Organizations are not indifferent to variances in the cost baseline. In order to meet expectations and build a trust-centric relationship it is important to discuss even challenging information openly. During the Roadmap planning process, EVM can be used to create an integrated baseline with time-phased budgets for resources and deliverables. In EVM, as work is performed and measured against the baseline, the corresponding budget value is “earned” when discrete deliverables are completed, hence the term Earned Value (EV). For agile, that would typically be at the end of the iteration, but it could be associated with specific features or stories. EVM has been in use since the 1960s and is a widely recognized program management technique. It is recognized by PMI as well as by many other organizations including the American National Standards Institute (ANSI), the International Performance Management Council (IPMC) and the Advancement of Cost Engineering International (AACEi). Earned Value Management (EVM) is a program management technique that integrates scope, schedule, and resource consumption information in order to measure project performance against planned cost metrics. It provides quantitative, objective data to supplement qualitative, subjective judgments. EVM’s fundamental premise is that as work is completed, the corresponding budget value is earned. That concept is in complete harmony with the agile premise that delivering working solutions in short iteration cycles demonstrates value being created. EVM work completed and agile measures stories completed. That alignment at the most basic level cannot be denied and means EVM calculations are perfectly adapted to agile’s iterative development process.

34

Although EVM can leverage many agile elements, in order to implement EVM the organization must define standards for data collection, analysis and reporting. The standards should define how much reporting detail the enterprise requires because as the need for more detailed or granular reporting increases the time and effort required to produce it increases.

Chapter Close-out In this Chapter we developed a comprehensive view of an enterprise-level agile model. We did so because many organizations are struggling with taking agile to the enterprise-level. That struggle means this content may be the most vital content in the whole book for some readers. It also acknowledges that the biggest opportunities in APM today exist for professionals who can take a micro-dynamic, team management framework and scale it up to a macro-dynamic, organizational framework.

The content moved beyond micro-dynamic team-level practices and into the agile practices that drive and guide enterprise maturity at the multi-project, program, portfolio and enterprise levels. In particular it explained how to:

• Integrate market and product development plans with agile processes • Deploy agile-aligned portfolio and program-level scheduling • Integrate architectural and engineering best practices with multi-project agile • Optimize agile estimating and risk management protocols • Deliver organizational control and reporting using Earned Value Management

The content faced the fact that every agile framework is missing two critical elements – sophisticated scheduling tools and accounting cost management. It addressed those challenges and provided an introduction to the deep dive into details that will follow in subsequent chapters.

35

Chapter Close-Out

Crossword Puzzle

Hints: Across 1 Driving variable in the agile enterprise. 3 Abbreviation for Minimal marketable features. 5 __________ network. 7 Cone of ___________. 9 Abbreviation for rough order of magnitude. 12 A deceptively simple way of documenting customer conversations. 13 Low-tech, __________.

Down 2 Abbreviation for Earned Value Management. 4 The critical path has zero ________. 6 Commitment to have conversations with the customer. 8 Written customer requirement used in the planning process. 10 A temporary group activity to produce a unique product or result. 11 Business functionality that the user needs in order to perceive value.

36

Word Search

Word Search - 15 Words to find:

• CARD • EVM • FEATURE • FLOAT • HIGH-TOUCH

• LOGIC • MMF • PROJECT • PROMISE

• ROM • STORIES • TIME-TO-VALUE • UNCERTAINTY

37

Answers – Crossword Puzzle

 

38

Answers – Word Search

 

39

Chapter End Notes 5 GR8PM subscribes to the following definitions. Rough Order of Magnitude (ROM) is used for long range planning and has an acceptable variance of -25% to +50%. Budgetary is used for mid-range planning and has an acceptable variance of -10% to +25%. Definitive is used for financial management and resource planning and has an acceptable variance of -5% to +10%. 6 Using the XS to XL scale is commonly referred to as “T-shirt Sizing.”