Scrum Master -Stephanie Volk
Product Owner – Doris Campbell
Team Coordinator – Reginald Sanders
Deliverables with brief descriptions for Scenario #3
- Product Vision– Provide power point slides with clear vision of the existing product.
- Team Evaluation– Collaborate with team members using Microsoft Teams, Word documents, excel files, UMGC library.
- Data Sheet– This will show a summary of product and all the requirements that is needed to execute this project including how it was managed.
- Release Plan– Track and show the development of the project.
9780321658395_final.pdf Chapter 6 The Envision Phase It’s the vision thing again! Visioning and goal setting have been identified time after time as key ingredients of project success. “It is rare to discover anything in the realm of human behavior that occurs with great consistency.…Therefore, it was surprising to find that in every case, without exception, when an effectively functioning team was identified, it was described by the respondent as having a clear understanding of its objective” (Larson and LaFasto 1989). But how does this need for a clear vision jibe with the exploratory nature of product development, which we have just gone to great lengths to describe as volatile and fuzzy? This apparent dichotomy is resolved when you con- sider that although the details of requirements and design can be volatile, the overarching business goal or product vision must be clear. In fact two critical aspects of a vision are clarity and an elevating goal that makes a dif- ference and conveys a sense of urgency to the project. Absent a clear vision, the exploratory nature of an agile project will cause it to spin off into endless experimentation. A clear vision must bound exploration. If everyone knows that creating a clear, compelling vision is so critical to project success, then why do so many teams suffer from lack of vision? The answer is that creating a clear, compelling vision is hard—it takes work, and it takes leadership. In the process of developing a new product there are so many options that creating a clear path forward can be daunting. This is one activity in which effective leaders lead—they help cut through the ambigu- ity and confusion of creating an effective vision. Compounding the prob- lem, there is no fixed rule for creating a good vision. It’s one of those “I’ll • 91 • Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith. Published by Addison-Wesley Professional. Copyright © 2009 by Pearson Education, Inc. know it when I see it, but I can’t describe it” phenomena, in part because the essence of a good vision is the teams’s articulation of it. Figure 6-1 depicts the evolution of a project plan—from vision, to scope, to release—utilizing three simple but powerful practices: the vision box, the project data sheet, and the release plan (accomplished in the Specu- late phase). Each of these artifacts is simple in concept, powerful, and low ceremony (informal), and operates on the principle of limited “real estate.” The vision box exercise forces the team to condense information about a product vision onto two flip chart pages (front and back of a box). The proj- ect data sheet forces the team to condense key project scope and constraint information into a single page. Story cards force the team to condense the key information about a story onto a single index card. Limiting the space in which we record information requires focus and selection: It demands col- laboration and thinking, and it compels the team to make effective tradeoffs. • 92 • T H E E N V I S I O N P H A S E Figure 6-1 The Evolution of a Project Plan Product Vision (Vision Box & Elevator Test Statement) Release Plan (Project) Project Scope (Project Data Sheet) Project Data Sheet :redaeL tcejorP:emaN tcejorP :rosnopS evitucexE:etaD tratS tcejorP Clients: Client Benefits: Project Objective Statement: Performance/Quality Attributes: Focus Matrix: Excel Improve Accept Target Scope Schedule Defects Resource Features: (Ability to Statements) Architecture: Major Milestones: Issues/Risks: Date 1. 2. 3. 4. 1992-97 Knowledge Structures, Inc. This chapter approaches the Envision phase as it would unfold for a new product and a new project, so the activities would need to be selected and adapted for other situations. For example, for a software product enhance- ment release, the vision should be done for the enhancement theme, not the overall product. A preliminary vision box and project data sheet could also be developed in a conceptualization phase early in a product life cycle. Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith. Published by Addison-Wesley Professional. Copyright © 2009 by Pearson Education, Inc. A Releasable Product In Chapter 1, the foundation for agile project success was defined as • Value goal: Build a releasable product • Quality goal: Build a reliable, adaptable product • Constraint goal: Achieve value and quality goals within acceptable constraints These are strategic goals, not specific requirements. They help teams and management answer the key questions at the end of every iteration: “What defines a releasable product?” and, “What is keeping us from releasing this product today?” These are very different from: “Are we conforming to our plan?” Circumstances, say a revised business objective, may lead to a “releaseability” answer that differs substantially from the plan. For example, the decision to release a product at an industry conference might alter the definition of minimal acceptable release capabilities. Focusing on the strate- gic releaseability question, rather than looking at a detailed requirements checklist, provides the entire project community with the right incentives to adapt to a changing environment. One release criteria for a product is that features or stories are “done- done”—done from both a development perspective (coded, unit tested, etc.) and a product team perspective (acceptance tested). The project com- munity and the organization define what production quality—done-done— means. For a life-critical medical device the quality threshold would be higher than for video games. Nonetheless, for a specific project defined pro- duction quality is a given, not a tradeoff option. In looking at the three areas that define a releasable product, informa- tion from the product vision box and project data sheet (PDS, both to be defined in this chapter) can be used: • A releasable product: product vision box; PDS—Project objective statement, business objectives, capabilities, capability value (defined in Chapter 8) • A reliable, adaptable product: PDS—Quality objectives • Within acceptable constraints: PDS—Tradeoff matrix (scope, sched- ule, cost) • 93 •A R e l e a s a b l e P r o d u c t Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith. Published by Addison-Wesley Professional. Copyright © 2009 by Pearson Education, Inc. Negative answers to the releasable question can be caused by a variety of fac- tors: a missing capability, a key capability that wasn’t mature enough, too much accumulated technical debt, or too many unfixed defects. These negative answers then become inputs to adapting strategies for subsequent iterations. Using this “releasable” product approach, progress discussions with exec- utives take on a different flavor. They revolve first around value, objectives, key capabilities and what has been delivered to date on the project (refer to the parking lot diagram in Chapter 10, Figure 10-2) and quality issues. These dis- cussions set a context for talking about cost and schedule, whereas in many non-agile environments, cost and schedule progress dominate. Envisioning Practices The purpose of the Envisioning phase is to clearly identify what is to be done and how the work is to be accomplished. Specifically, this phase answers the following questions: • What is the customer’s product vision? • What are the key capabilities required in the product? • What are the project’s business objectives? • What are the project’s quality objectives? • What are the project constraints (scope, schedule, cost)? • Who are the right participants to include in the project community? • How will the team deliver the product (approach)? For small projects, much if not most of the work of the Envision and Specu- late phases can be accomplished in a single “kickoff” chartering session. For larger projects, chartering, requirements-gathering, additional training, resource procurement, and architectural work may take longer and can be included in an Iteration 0 (see Chapter 7 “The Speculate Phase”). For large- to medium-sized projects, there is normally a debate and discussion period required to obtain agreement about the product vision. During the Envision phase the vision constantly evolves based on new information. After the • 94 • T H E E N V I S I O N P H A S E Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith. Published by Addison-Wesley Professional. Copyright © 2009 by Pearson Education, Inc. Envision phase it needs to be reviewed periodically for any changes and to ensure that the team continues to understand the vision. Although there are other important aspects of initiating a project, such as budgets, staff organization, and reporting needs, without a commonly held vision the project will falter. Without a vision, “initiation,” on its own becomes bureaucratic and sterile. The Envision phase defines the beginning of a project for which the kick-off event might be the approval of a feasibility study. Many companies conduct feasibility and marketing studies prior to initiating development projects, whereas others use only brief project requests. Envisioning should involve the development and product team members in this process, nor- mally using a series of collaborative meetings. In the Envision and Speculate phases of APM it is particularly impor- tant to remember that • The team members should constantly ask the question, “What is the barely sufficient process and documentation that we need?” • All the practices related to “how” a team delivers are tailored and adapted to improve performance as the project progresses. • The project community will also evolve its teaming practices. The practices explained in this chapter fall into four categories: visions for product, project, community, and approach. • Product Vision • Product vision box and elevator test statement • Product skeleton architecture and guiding principles • Project Objectives and Constraints • Project data sheet • Project Community • Get the right people • Participant identification • Customer team-development team interface • Approach • Process and practice tailoring • 95 •E n v i s i o n i n g P r a c t i c e s Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith. Published by Addison-Wesley Professional. Copyright © 2009 by Pearson Education, Inc. Product Vision A product vision (defined by a product vision box and elevator test state- ment) galvanizes members of the product team into focusing their often dis- parate views of the product into a concise, visual, and short textual form. These two project artifacts, and the product roadmap, provide a “high con- cept” of the product for marketers, developers, and managers. Although a preliminary product vision may have been done during a conceptualization phase, few members of the delivery team are usually involved in that process. Teams may take that vision as input, but it’s critical that the team revisit that preliminary work. Innovation, creating emergent results that we cannot predict, requires an evolutionary process that can accommodate exploration and mistakes. A