1. 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. 2 CSE 4316 2 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

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

4. 2 CSE 4316 4 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!

5. 2 CSE 4316 5 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?

6. 2 CSE 4316 6 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

7. 2 CSE 4316 7 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

8. 2 CSE 4316 8 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

9. 2 CSE 4316 9 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

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

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

12. 2 CSE 4316 12 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.

13. 2 CSE 4316 13 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.

14. 2 CSE 4316 14 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.

15. 2 CSE 4316 15 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.

16. 2 CSE 4316 16 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.

17. 2 CSE 4316 17 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.

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

19. 2 CSE 4316 19 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

20. 2 CSE 4316 20 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.

21. 2 CSE 4316 21 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

22. 2 CSE 4316 22 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