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

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

3. Team home page

4. Work items

5. 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

6. 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

7. Summary of work items
Impediments

8. 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

9. 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

10. EXample backlog

11. work items

12. adminstration

13. Team home page
Control Panel

14. Control panel

15. 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

16. 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

17. 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

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

19. Team settings

20. 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

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

22. alerts

23. Control panel

24. Das delivery model

25. Das delivery model overview

26. release planning

27. 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

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

29. 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

30. 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)

31. Create release backlog

32. 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

33. 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.

34. 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

35. Create sprints

36. Create Release plan

37. Sprint planning

38. 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.

39. Sprint backlog

40. Sprint Capacity

41. sprint planning

42. Sprint execution

43. 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

44. Sprint board – by backlog items

45. Sprint board – by people

46. Reports and queries

47. 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.

48. 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.

49. 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.

50. 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.

51. queries

52. reports and queries

53. Review and retrospective

54. Das delivery model overview

55. 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

56. 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

57. 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

58. 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

60. APPENDIX “A” – Work items

61. Release work item

62. Epic work item

63. Feature work item

64. Pbi work item

65. Task work item

66. Bug work item

67. Impediment work item

68. 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 for a detailed description of DTTL and its member firms. Please see 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 Member of Deloitte Touche Tohmatsu Limited