PDM-Project Delivery Methodology iDeaWORKS Journey from Good to Great Version: 1.0 Date: Feb 27, 2012

Pursue of excellence in project delivery, efficiency and effectiveness to ensure that all iDeaWorks stakeholders are WINNERS. Demonstrate to Mohawk students a fully functional software project delivery life cycle from inception to transition. Ensure compliance with iDeaWorks quality assurance standards to set ground work needed to pursue quality assurance certifications such as ISO.

Project Validation Project Initiation Project Design Agile Development Project Close Out Quality

PhasesINPUTPROCESSOUTPUTQAssurance Pre Inception1- Idea/Need 2- Stakeholders Acceptance Criteria 3) Project priorities 4) Constraints Project Validate1) Preliminary Requirements 2) Statement of Work 3) Funding Approval 4) Project Charter 1) Risks Evaluation 2) Scope Boundaries Analysis 3) Deliverables Approvals Needed 4) Resources Limitations Inception1) Project CharterProject Initiation 1) Scope 2) Architecture 3) Detail Requirements & Stories Use cases 4) Project Plan 5) Release Engineering Setup 6) Initial Prototype 1) Risk Countermeasures 2) Deliverables Approvals 3) Status Reports 4) Requirements Matrix DB design standards 5) Architecture Design Standards 6) Requirements gathering Standards Elaboration1) Scope 2) Architecture 3) Detail Requirements Use cases 4) Project Plan 5) Release Engineering Setup 6) Initial Prototype Project Design1) Final Architecture 2) Detail 3) Specification 4) Database Design 5) Product Catalogue 6) Sprint Backlog 7) Prototype 8) Acceptance Test Cases 1) Deliverables Approvals 2) Status Reports 3) Project Design Review 4) Requirements Matrix 5) DB design standards 6) Architecture Design Standards 7) Requirements gathering Standards Construction1) Final Architecture 2) Detail 3) Specification 4) Database Design 5) Product Catalogue 6) Sprint Backlog 7) Prototype 8) Acceptance Test Cases Agile Scrum Development of Sprints 1) Increments of Deliverables 2) Final Product Deliverables 1) Deliverables Approvals 2) Status Reports 3) Code Reviews 4) Requirements Matrix 5) UI design standards 6) Testing and QA standards 7) Coding Standards Transition1) Final Product Deliverables 2) Project Contractual Documentation Project Close Out 1) Customer Signoff 2) Sponsor Signoff 3) Lessons learned 4) Close Out Report 1) Sponsor Feedback 2) Customer Feedback 3) iDeaWorks Feedback 4) Partners/Vendors Feedback

Basic unit in Scrum. Tasks are initiated for the sprint goal (team creates finished portions of a product) Timeboxed = Restricted to a time duration (Week to Month) The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format The product backlog is the “What” that will be built, sorted in the relative order it should be built in. Make SMART Requirements: Simple, Measurable, Achievable, Realistic, Traceable. User Stories INVEST in User Stores: Independent, Negotiable, Valuable, Estimable, Small, Testable. Tasks Make sure a Task is TECH. Time boxed, Everybody (can pick it up), Complete and Human-readable. The sprint backlog is the list of work during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until there is enough work to fill a sprint. The stories/features are broken down into tasks by the DevTeam, which, as a best practice, should normally be between four and sixteen hours of work. Task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”. Increments of Final Deliverable Product Backlog Sprint Backlog SprintFinal Deliverables

Stakeholders (customers, vendors) Product OwnerScrumMasterDevelopment TeamAncillary roles Who enable the project and for whom the project will produce the agreed- upon benefit[s], which justify its production Owns the Product Backlog The Product Owner represents the interests of everyone with a stake in the project (Stakeholder) and he is responsible for the final product. elicit product requirements manage the Product Backlog manage the release plan manage the Return on Investment The Scrum Master is responsible for the Scrum process. He ensures everybody plays by the rules. He also removes impediments for the Team. The Scrum Master is not part of the Team. manage the Scrum process remove impediments facilitate communication The team figures out how to turn the Product Backlog into an increment of functionality within a Sprint. Each team member is jointly responsible for the success of each iteration and of the project as a whole. software quality technical implementation of User Stories delivery of a “potentially shippable” product increment at every Sprint Those with no formal role and infrequent involvement in the Scrum process—but nonetheless, must be taken into account.

Daily Scrum Timebox: 15 Minutes Owner: Scrum Master Participants: Team, all interested parties may silently attend. Backlog grooming Story time Timebox: 1 hours Owner: Product Owner Participants: Architect,Scrum Master, optionally the PO can invite other Stakeholders Scrum of Scrums Timebox: 15 Minutes Owner: Scrum Master Participants: Team, all interested parties may silently attend. Sprint Planning Timebox: 4 hours Owner: Team Participants: Scrum Master and Architect Sprint Review Timebox: 4 hours Owner: Team Participants: Scrum Master, Product Owner, optionally the PO can invite other Stakeholders Sprint Retrospective Timebox: 3 hours Owner: Scrum Master Participants: Team, (Product Owner) The meeting starts precisely on time. Normally only the core roles speak. The meeting should happen at the same location and same time every day During the meeting, each group member answers three questions: What have you done since yesterday? What are you planning to do today? Any impediments/stumbling blocks? It is the role of the ScrumMaster to facilitate resolution of these impediments, although the resolution should occur outside the Daily Scrum itself to keep it under 15 minutes. The group should spend time during a sprint doing backlog grooming. This is the process of Prioritizing the Product Backlog, estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories. The Meeting does not include breaking stories into tasks. The group can decide how many meetings are needed per week. Each day normally after the Daily Scrum. These meetings allow clusters of groups to discuss their work, focusing especially on areas of overlap and integration. A designated person from each group attends. The agenda will be the same as the Daily Scrum, plus the following four questions: What has your group done since we last met? What will your group do before we meet again? Is anything slowing your group down or getting in their way? Are you about to put something in another group’s way? At the beginning of the sprint cycle (every 7– 30 days), a “Sprint planning meeting” is held. Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work, with the entire group Identify and communicate how much of the work is likely to be done during the current sprint prioritizing the Product Backlog Hashing out a plan for the Sprint, resulting in the Sprint Backlog At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective” Review the work that was completed and not completed Present the completed work to the stakeholders Incomplete work cannot be demonstrated. All group members reflect on the past sprint Make continuous process improvements Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Three hour time limit.

The Product Backlog is the master list of all functionality desired in the product. During the Sprint Planning Meeting the Product Owner prioritizes the items in the Product Backlog and describes them to the team. The team then determines which items they can complete during the coming Sprint. The team then moves items from the Product Backlog to. the Sprint Backlog In doing they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized Product Backlog list and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, the top five items and then two items from lower on the list but that are associated with the initial five. This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product Owner. Estimates have been developed by the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints. Story IDStory nameStatusSizeSprintPriorityComments 1This is a sample storyDone31 2This is another sample storyOngoing51You can add comments here to add key detail or explanation to the story. For larger definitions, use external tools and materials. 3This is a third sample storyPlanned32 4This is a fourth sample storyPlanned83 5This is an unallocated sample storyPlanned13 6This is a removed storyRemoved5

Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team's perception of the time it will take to complete the various features. It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to. The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. An example of the Sprint Backlog in Excel looks like this: SprintStartDaysEndSizeStatus Release DateGoalIncrement 113/06/ /06/20068PlannedPlanning1 227/06/ /07/20063PlannedSpecification and prototype development1 311/07/ /07/20068PlannedSpecification and prototype development1 425/07/ /08/20060PlannedSpecification and prototype development2 508/08/ /08/20060PlannedSpecification and prototype development, documentation2 622/08/ /09/20060PlannedUsability test, documentation, prototype corrections2 Unplanned Unallocated stories 13

Sprint implementation days5 EffortRemaining on implementation day… Trend calculated based on last5DaysTotals Task nameStory IDResponsibleStatusEst Example task1Danny DevDone5520 Example task 21Tina TesterOngoing77722 Example task 32Danny DevOngoing Planned99999 Story ID:1Story:This is a sample story Task:Example task Responsible Person: Danny Dev Initial Estimate 5 Work Done Work Left Story ID:1Story:This is a sample story Task:Example task 2 Responsible Person: Tina Tester Initial Estimate 7 Work Done Work Left Summary Sprint Tasks Task Card