CSE Senior Design I Building a Plan Instructor: Mike O’Dell Several of the slides in this module are a modification and amplification of slides prepared by Mr. Tom Rethard for use in a prior Senior Design Class. They were originally for use with A Discipline for Software Engineering (Watts S. Humphrey), sponsored by the U.S. Department of Defense. Original slides are copyright SEI; modifications are Copyright © 2002, T. Rethard. Further modifications by Mike O’Dell. All Rights Reserved.

2 CSE Why Plan? focus  A plan helps you focus on the goal  “Begin with the end in mind. 1 ” estimate  A plan let’s you estimate job completion track progress  A plan helps you track progress milestones sense of accomplishment  A plan gives you milestones that provide a sense of accomplishment along the way identify problems  A plan helps you identify problems early establishes commitments  A plan establishes commitments for the team and each individual on it 1 Stephen R. Covey, The Seven Habits of Highly Effective People

2 CSE The Planning Process… Simplified  Plan the work … then work the plan  Refine, refine, refine…

2 CSE What is a Plan? agreement  An agreement by the team on the cost and schedule for a specified job structure  A structure for organizing the work framework  A framework for obtaining the required resources (people, funds, etc.) record  A record of what was initially assumed and committed CONTRACT  It’s a CONTRACT!

2 CSE Components of a Plan Lifecycle  A Lifecycle Planning Model: The Master Plan for the Project  Order and criteria for key events  Correct model for the job?  Work Estimates  How big is the job (size and effort)?  What can be done with resource/time?  Schedule and Work Breakdown  When do we expect to have things done?  What are we committing to?

2 CSE Representative Lifecycle Models  Pure Waterfall (the old granddaddy)  Code-and-Fix (and plan to fail)  Spiral (new age sophistication)  Modified Waterfalls (making the best of an old standby)  Evolutionary/Rapid Prototyping (design as you go)  Agile development – iteration in timeboxes  Staged Models (show as you go)  Design to schedule combination  Hybrids – some combination of above

2 CSE Agile Methodologies  Iterative and incremental development  Adaptive planning based on customer and market changes  Plan milestones are flexible and subject to change  “rolling wave” progression  TimeBox development  Staged (potentially shippable increments)  Scrum

2 CSE Clear Product Specifications what how  Provide the details of what will be done, and how it will be done: what  Requirements Specification (SRS – what), managed via the Product Backlog how  Design Documentation (DDS - how )  Test Plan (verify the what and the how)  These provide the basis for product acceptance

2 CSE Processes/Procedures how  Defines how things will get done  Provides the basis for establishing critical milestones and deliverables  Establishes entry and exit criteria for critical phases  Establishes the standards that will be used  Defines the tools that are required to complete the work

2 CSE 4316 (from Essential Scrum, Rubin) 10 Scrum Overview  Scrum Essentials  Roles  Activities  Artifacts

2 CSE 4316 (from Essential Scrum, Rubin) 11 Scrum Activities Overview

2 CSE Characteristics of a Good Requirement (PBI/User Story)  Independent.  Independent. One of the characteristics of Agile Methodologies such as Scrum is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.

2 CSE Characteristics of a Good Requirement (PBI/User Story)  Negotiable.  Negotiable. The only thing that is fixed and set in stone in an agile project is a Sprint backlog (and, even then, it can be broken). While the story is in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by team members.

2 CSE Characteristics of a Good Requirement (PBI/User Story)  Valuable.  Valuable. The focus here is to bring actual product-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user violates one of the Agile Principles, which is to continuously deliver valuable software.

2 CSE Characteristics of a Good Requirement (PBI/User Story)  Estimable.  Estimable. If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of an iteration. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the time, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

2 CSE Characteristics of a Good Requirement (PBI/User Story)  Small.  Small. User story sizes should typically take only a few days to implement. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in a Sprint backlog comes closer.

2 CSE Characteristics of a Good Requirement (PBI/User Story)  Testable.  Testable. Bear in mind that a story should only be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimable" above), the story should not be considered a good candidate to be part of a Sprint Backlog.

2 CSE Characteristics of a Good Requirement (PBI/User Story) I.N.V.E.S.T.

2 CSE Tips for Successful Requirement Determination features/functions  Start by establishing what the team thinks the features/functions of the system should be  Brainstorm as team and write everything down on the Product Backlog (using the template provided) sponsor  Meet with your sponsor to review/modify your list and discuss alternatives  Add any features/functions that the sponsor believes are required

2 CSE Tips for Successful Requirement Determination ancillary requirements  Consider and add ancillary requirements  E.g., performance, packaging, look and feel “non- functional” requirements  Discuss and add as necessary any “non- functional” requirements  E.g., standards that you must adhere to, maintenance and support, safety analyze the feasibility  Discuss and analyze the feasibility of meeting or exceeding each requirement within the budget, time and skills allowed. Assess effort required.

2 CSE What is a System Requirements Specification (SRS)? detailed description  A detailed description of the features and functions of a product, incorporating:  End-user and sponsor input  Developer input  Management input Product Backlog  The basis for your Product Backlog commitment  Your documented commitment to deliver contract  Your contract with your stakeholders that identifies WHAT you will create

2 CSE What is a Project Charter?  A document that summarizes the project  Defines the scope, product vison and objectives of the project  Delineates organizational relationships and key roles of the project team  Delineates individual authority and responsibility of those individuals  Identifies key risks and plans to handle them  Specifies dependencies on other organizations