TFS 2015 – DAS Delivery model Deloitte Application Studios (ITS) Updated 12/15/2015

CONTENTS Work Items Epics, Features, Stories Control Panel DAS Delivery Model Release Planning Sprint Planning Sprint Execution Reports & Queries Epics, Features, Stories States and Ready States Teams Areas Iterations Capacity Planning Task Board

Team home page

Work items

work items Release Deloitte custom work item that contains meta-data about the release to facilitate metric reporting Epics Are the business needs and goals of the Customer Typically implemented as one or more Features to accomplish the goals Acceptance criteria is focused on the business needs and goals May be fully realized across multiple Releases Features Application elements or other deliverables that enable the Customer to meet their Goals Examples: Screens, controls, workflows, reports, interfaces, web services Provide functionality that enables users to get the value described in User Stories Acceptance criteria is focused on the technical behavior of the element or the deliverable Must be delivered within a single Release PBI (User Stories: Business, Technical) Represent capabilities that enable a user to obtain a business goal or solve a problem Are written in the every-day language of the user Acceptance criteria is focused on the capability and user value provided Must be completed in a single Sprint Impediment

Tfs work items Bugs Deviations or errors in the behavior of features Unintended functionality that does not meet the needs or goals of the Customer Missing functionality required to deliver the value defined by a User Story May be resolved in a Sprint, a Release or future Release Are prioritized based on the needs of the Customer Tasks Represent work to be done by an individual on the Team Are typically executed as part of a User Story or to resolve a Bug Can be a stand-alone task Impediments Problems or road-blocks that impede the progress of the team Anything that might stop the team from meeting their goals Must be resolved immediately Impediment

Summary of work items Impediments

Work item states New Represent new PBIs (User Stories) Need further analysis, details, estimates, or other discussion before approval Approved The work item is approved by the Product Owner as ready for the team to implement Story-point estimates and Acceptance Criteria are complete and agreed-to Team believes the work item can be completed within a single Sprint Prioritized (force-ranked) by Product Owner and Team agreement Committed Tasks have been entered into TFS, with estimated hours on each task The work item is “locked down” – no changes are accepted into the current Sprint The team is committed to delivering this work item in the current Sprint Done All child items (e.g., tasks) of this work item are Done Final review of the work item has been presented during the Sprint Review (Demo) The Product Owner and Team agree the user story is complete per the Definition of Done and the Acceptance Criteria

ready states User Stories Bugs Features New Ready for Estimation Ready for Approval Approved Ready for Commitment Committed Ready for Design Ready for Development Ready for QA Ready for Demo Done New Ready for Estimation Ready for Approval Approved Ready for Commitment Committed Ready for Design Ready for Development Ready for QA Ready for Demo Done New In Progress Ready for Development Ready for Stabilization Ready for Production Done

EXample backlog

work items

adminstration

Team home page Control Panel

Control panel

TEAMS, AREAS, AND ITERATIONS Teams are connected to a Backlog of work items through an assigned Area Each Team can be assigned to one or more Areas Each Team has its own dashboard showing the work the team is responsible for Teams cannot be nested Areas Areas are used to define either logical, physical, or functional boundaries within a Project Provide a way to organize work items into more manageable, reportable, and easily identifiable groups Security can be applied to Areas to control which Teams can view or edit work items Areas can be nested Iterations Are used to divide work into time-boxed segments for execution and reporting Are used for Releases and Sprints Iterations are nested: e.g., Releases have multiple Sprints

Teams, areas, and iterations working together Use Teams, Areas, and Iterations to organize the work Teams each have a separate view into the backlog Teams may work in multiple Iterations and Areas Iterations time-box the work for tracking progress Areas divide the work into separate groups

teams Team Project Teams Provide a view into the backlog Teams are not nested Are self-managed Default Team View of the entire backlog Product Team Manage Releases, Epics, Features Typically includes the Studio Team May include Stakeholders Development Team Manage User Stories, Tasks Typically includes Studio Team and Pod members

Team members Product Team Selected Team Members Add members using their Deloitte email address Administrators Can add or remove Members Can add or remove Iterations Can add or remove Areas Can alter team Settings

Team settings

areas Areas Selected areas hold backlog items the team owns Teams can see work items in selected areas, and parents and children in other areas Typically not needed to include sub- areas

iterations Backlog Iteration Unscheduled backlog candidates Iterations Current Release will become Pod’s backlog

alerts

Control panel

Das delivery model

Das delivery model overview

release planning

Release planning Step 1: Create a Release Backlog Identify the Epics, Features, and User Stories to be included in the Release Ensure all work items have acceptance criteria Create story point estimates for each story Prioritize the Stories Step 2: Determine Sprint Duration Feedback cycle is the primary consideration when determining the Sprint Length Shorter sprints = faster reaction to change; Longer sprints = slower reaction to change Recommended Sprint duration is two weeks Step 3: Determine Maximum Estimated Velocity Determine Maximum Estimated Velocity: How many points the team can complete in a single Sprint based on the Definition of Done Teams will schedule features for each sprint, ensuring maximum estimated velocity is not exceeded Teams should consider using less than maximum estimated velocity to allow room for change Conversation must happen with the customer to determine the buffer Suggested to plan at 80-90% of maximum estimated velocity

Iterative Design and Planning Create a release backlog Iterative Design and Planning

The chicken and the egg Customers may provide Epics, Features, or Stories at any time Capture and consider everything the Customer wants Listen, advise, revise, review, refine, and organize The Backlog grooming process is iterative The Product Backlog is a living repository

Acceptance criteria Acceptance Criteria Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended Acceptance criteria is (usually) from the perspective of the customer or stakeholder Can be centered around solving a business need (Epics), or functionality (Features), or system behavior (Stories) Benefits of good Acceptance Criteria They get the team to think through how a feature or piece of functionality will work from the user’s perspective They remove ambiguity from requirements They form the tests that will confirm that a feature or piece of functionality is working and complete Tips Ask the customer or stakeholder how they will know the business problem is solved Think in terms of “When the user does this, the system should do this” “When the system provides this information, the customer can make this decision” Too much acceptance criteria may indicate the story should be broken into smaller parts (look for actions vs. confirmation)

Create release backlog

Story point estimating Story Points vs. Hours Story points are estimates and represent a range of difficulty, complexity, and effort Hours are commitments – Customers will never see them any other way Story points convert to hours using the team’s current velocity Sizing new stories with an existing backlog Compare the new story to existing stories and place in the appropriate bucket “It’s bigger than everything we’ve called a 5 and smaller than everything we’ve called a 13, therefore it must be an 8” Sizing new stories without an existing backlog Force rank all user stories by team consensus – smallest/easiest to largest/hardest Group stories into similar-sized groups Assign the same number of story points to all stories in the group Consider using the Fibonacci sequence Tips Do consider all aspects of the story to determine it’s size Do change the number of story points if the scope or acceptance criteria changes Don’t change story points based only on how much work it actually took to complete a story Don’t change story points to match a desired velocity

Definition of done – user stories Tech specs are complete and signed off by the Architect. Studio Team and Business Product Owner agree that all functional and non-functional requirements (e.g., performance, accessibility, security) are represented in the Acceptance Criteria. Functional test cases that reflect all Acceptance Criteria are written and agreed-to by the BSA and the Business Product Owner. Code has been completed, refactored, commented, checked in and run against the current version in source control. Code meets all design and development standards. All unit tests are written and pass. The Solution builds without errors. All QA functional tests have been executed in QA environment, with zero critical or high defects, and a minimal, pre-agreed number of medium/low. Target is set as a team before the sprint begins. Business Product Owner agreement that the completed functionality meets the business requirements per the Acceptance Criteria. All build, deployment, or configuration changes have been implemented, documented, and communicated. All relevant documentation is up to date and approved by the EM, Architect, BSA, and Business Product Owner, as appropriate. All “To Do” items for the story are completed and marked as “Done” in TFS.

Determine sprint duration Feedback loop Length of feedback loop is the primary determination of Sprint length Shorter sprints enable quicker feedback to customer Shorter sprints provide more opportunities to adjust Shorter sprints are faster to plan, demo, and review All build Sprints should be the same length – Two weeks is suggested Two-week Sprints Three-week Sprints Start Demo Feedback Deliver

Create sprints

Create Release plan

Sprint planning

Sprint planning Step 1: Identify Stories to be completed in this Sprint Team discusses each candidate story to be sure they understand the details. Acceptance criteria must be clear and agreed-to by the Team and Customer. Stories must be force-ranked by priority. Use your team’s velocity to limit the number of candidates in the Sprint Step 2: Define tasks to complete each item Team creates tasks in TFS for all actions necessary to complete a story based on the Definition of Done. Estimate all tasks in hours, usually between 4 and 16 hours. Assign tasks to team members and Activity (e.g., Development, Testing, etc.) Step 3: Adjust work to fit team capacity Enter each team member’s Capacity and Activity in TFS. Team over capacity: Move stories out of the Sprint. Team under capacity: Move stories into the Sprint. Load-balance work across the team. Plan at 80-90% of capacity.

Sprint backlog

Sprint Capacity

sprint planning

Sprint execution

Sprint execution Story and Task Execution Work on the highest-priority stories first Put as many people as possible on the story to get it Done as quickly as possible Avoid “Scrum Fall” Daily Scrum All tasks should be updated with remaining hours during or prior to the call All team members must attend Review the backlog by item and by person to get a full view of the activity Review the burndown chart – discuss trends

Sprint board – by backlog items

Sprint board – by people

Reports and queries

Backlog overview Define PBIs and tasks. Make sure that tasks are linked to their parent PBIs If you subdivide a task into subtasks, specify hours only for the subtasks. Hours are roll up as summary values for the parent task and PBI. Define and update the State and Remaining fields for each task or subtask during the iteration or release. Define test cases and link test cases to their parent PBIs using the Tested By link. Specify the Iteration and Area paths for each PBI, task, and test case.

Sprint burndown Schedule sprints for your team. Define tasks for each product backlog item you’re working on within the sprint. Specify and update the Remaining Work field for each task or subtask as it is worked on. If you divide a task into subtasks, specify hours only for the subtasks. These hours are rolled up as summary values for the parent task. Update the State of each task as it progresses from To Do to Done.

Release burndown Specify the number of releases you want to track and define the start and end dates for each sprint. Define product backlog items and bugs, and assign each to a sprint or iteration. (Iteration field). Make sure that all backlog items are assigned to your team’s area path or subarea. At the start of a release, estimate the Effort for each product backlog item and each bug that your team will work on. During the sprint or at the close of each sprint, for each product backlog item and each bug that the team completed, change the State to Done.

velocity Schedule sprints for your team. Define product backlog items and bugs, and assign them to an Iteration and to your team’s Area path. Specify and update the Effort for each product backlog item and each bug that is active. Update the State of each product backlog item and each bug as it progresses from New to Done.

queries

reports and queries

Review and retrospective

Das delivery model overview

Review and retrospective Review / Demo Demonstrate all new functionality created in the Sprint Use Acceptance Criteria to guide the demo Seek the Stakeholder’s approval to mark the Story as Done, based on the Acceptance Criteria Create new Stories based on the Stakeholder’s feedback. Understand their priority to the Stakeholder. Retrospective What do want to start doing, stop doing, continue doing Review your team velocity. If it deviated from the estimate, discuss why Come up with a few immediate actions for the team to try in the next sprint Consider using the Retrospective Talking Points document as a guide

Managing change Formal Change Request: Scope changes - New or changed Epics or Features Scope changes – New or changed User Stories that exceed the planned buffer Changes to Timeline or Cost No Change Request Necessary: Changes to User Stories that do not result in a change in Story Points New or changed User Stories that fit within the velocity buffer Re-prioritized User Stories or Features that do not impact the timeline or cost

Rollout schedule TFS 2015 Upgrade: TFS will be upgraded to 2015 version the weekend of 12/11 – 12/13 TFS will be unavailable from Friday night through Sunday afternoon No template changes will be pushed with this upgrade Template Upgrades: In-flight projects – Schedule with SCM to have your template updated during the “HyperCare” period of your project New projects for existing products – Schedule with SCM to have your template updated during Sprint Zero New products – New TFS projects will be created with the new template starting January If you need an exception, please reach out to Kevin Gibson

Final thoughts Our Manifesto … Favor individuals and interactions over processes and tools Favor working software over comprehensive documentation Favor customer collaboration over contract negotiation Favor responding to change over following a plan And most importantly … Common sense should always prevail

APPENDIX “A” – Work items

Release work item

Epic work item

Feature work item

Pbi work item

Task work item

Bug work item

Impediment work item

About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. Please see www.deloitte.com/about for a detailed description of DTTL and its member firms. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting. Copyright © 2015 Deloitte Development LLC. All rights reserved. 36 USC 220506 Member of Deloitte Touche Tohmatsu Limited