Scrum with TFS 2008

1. Scrum with TFS 2008 Scott Colestock

2. Scott Colestock • Focus on ALM space with VSTS/TFS (speaking/writing/production rollouts) • Consulting independently in the BizTalk 2004/2006 space for about 5 years • Blog: www.traceofthought.net

3. Agenda • VSTS & Lifecycle Management • Whirlwind Scrum Tour • Conchango Scrum Template • eScrum Template (from Microsoft) • VSTS Lightweight Scrum Template (brief)

4. VSTS & Lifecycle Management • Application lifecycle management (ALM): Process of delivering software as a continuously repeating cycle of inter-related steps1: • Definition, design, development, testing, deployment and management. • Apart from tooling…ALM has to address: • What (processes/deliverables) • How (techniques) • Who (roles) 1: wikipedia

5. VSTS & Lifecycle Management • Many challenges to organizational adoption of formal ALM… • Processes can be complex; often defined in reference documents only • Life cycle tools traditionally poorly integrated with engineering tools • Project management, requirements management, bug tracking, review management • Versus tools that support design, coding, testing, debugging, classic IDE functions The ALM toolbox…

6. VSTS & Lifecycle Management • Tool mismatch (management vs. engineering) makes process analysis unreliable. • Many projects treat a Microsoft Project Plan as source-of-truth, until reality steps in… • Difficult to identify process improvement opportunities or measure process adherence • Or more importantly, measure process cost/benefit ratio

7. What if my development process was implemented directly inside of developer tooling? What if all necessary data capture was part of the normal developer workflow?

8. VSTS & Lifecycle Management • VSTS “implements” life-cycle methodologies using process templates • Process templates are associated with a Team Project - • Project Creation Wizard (PCW) asks you to choose a template… • PCW then provisions Team Project resources according to the definitions in the process template (xml files)

9. Process Template Content • Work item types, work item queries, reports, process guidance, source control policies, etc. • Apart from source artifacts & builds, “work items” are the core entity that TFS tracks! • Recognizing that enacting a given process really comes down to: • What information will I track • What metrics will I pay attention to • What practices will I emphasize/enforce • What phases/cycles do I engage in • What roles must be filled…

10. Choosing/Customizing aProcess Template • Choose a base template that fits shop well for work item types, work item queries, and reports • MSF for Agile, or MSF for CMMI, or Others (Scrum templates, etc.) • Decide if you’re going to customize your team project, or create a new process template… • Just your project: modify work item types & queries “in place” (directly against your team project) • Creating a new process template (from a base template): download the template, modify, and upload. • Customize! • Typically begin with work item types and work item queries • Move outward to reports, sharepoint site, document templates, process guidance, default version control policies, etc.

11. Choosing/Customizing aProcess Template • Much discussion on process templates focuses on “process guidance” – how to package the description of the methodology • Reality: Most shops (initially) just want work item types that align with the “lists” they keep (e.g. requirements, tasks, bugs, etc.) • Work items can comprise not just fields, but simple workflow (state transitions with entry/exit criteria) and can exist within area/iteration hierarchy

12. Customizing a Process Template • Customization of work item types and work item queries is quite easy • WITImport/WITExport command line tools • TFS Power Tool has process template editor (tinyurl.com/tfs08tools)

14. Agenda • VSTS & Lifecycle Management • Whirlwind Scrum Tour • eScrum Template (from Microsoft) • Conchango Scrum Template • VSTS Lightweight Scrum Template (brief)

15. Why a Scrum Template? • MSF for Agile/CMMI: • Difficult to find broadly-available documentation on MSF for Agile/CMMI • Process guidance for MSF templates can be difficult to use as a tutorial… • Few classes/certifications on new MSF material • Appropriate for teams steeped in iterative development who can view MSF as another in a family of methodologies • Scrum: • Good industry critical mass; many good books & web site resources • Certification process, formal training infrastructure • Process guidance for the Conchango template is quite good

16. Scrum is… • A deceptively simple framework for managing complex projects • A simple team model • A simple process model • With very few artifacts… • Does remarkably good job of stripping away project elements: • That have no value… • That subtract value (i.e. useless tax) • That hide the actual condition of the project • Attempts to adhere to Scrum often reveals complex project and org issues (outside agendas) – can cause adoption to fail

17. Scrum has… • Scrum has a team model • (roles to play) • Scrum has a process model • (a rhythm to follow) • Scrum has a set of artifacts • (lists/backlogs to create, data to gather)

18. What is Scrum? 24 hours Daily Scrum Meeting (facilitated by Scrum Master) Backlog tasks decomposed by team 30 day Sprint Sprint Backlog Potentially Shippable Product Increment Product Backlog As prioritized by Product Owner Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

19. Scrum Elements • Roles: Product Owner, Scrum Master, Team • Process Model: • Sprint planning • Sprint, with Daily Scrum • Sprint Review (Demo) & Delivery • Sprint Retrospectve • Artifacts: • Product backlog • Sprint backlog • Sprint burndown chart • Product increment

20. Scrum Elements Conchango

21. Scrum Elements Conchango

22. Artifact 1: The Product Backlog(deceptively simple) • A list of product requirements – functional and non-functional • “As a <role> I want <ability> so that <benefit>” • Prioritized by organizational value • At some point, must decide whether xyz revenue-generating feature is more or less important than pdq SOX compliancy feature • Each item expressed such that it is no coarser than a Sprint in size • Else attempt to express as a smaller “increment in business value” • Estimate in days or story points • Simple Excel worksheet can do…(title, estimated sprint, duration, owner) • Never finalized – emerges and evolves with the product • So you begin delivery with just a handful of information (no big up-front requirements process) • Information about what is the highest priority right now…

23. Scrum Elements Conchango

24. Team Element 1: The Product Owner • The Product Owner owns the Product Backlog… • Though anyone can contribute Product Backlog items (PBIs) • Product owner able to reprioritize any backlog item that is not in the currently-running Sprint • One person in this role ensures that only one set of requirements drives development team’s focus – influenced by committees, management, customers, sales people • Works with others to estimate items (in days or story points) on Product Backlog • Ideally focus is ROI. • Product Owner steers the project via Product Backlog prioritization to provide the greatest/fastest ROI to the organization. • Owns the definition of success.

25. Scrum Elements Conchango

26. Process 1: Sprint Planning Meeting • Part 1: Product Owner selects the ideal product backlog items for the coming Sprint and communicates the value of this increment in business value to the team • For each PBI, how will we demo? • Some PBIs may need to be decomposed to fit into Sprint • Part 2: The team decides how much it can commit to delivering in the coming Sprint • The Team decides how to turn the selected backlog items (or “top x”) into an increment of potentially shippable product functionality. • The Team devises its own tasks (Sprint Backlog Items) and figures out who will do them, and what estimates to assign • The Team will quickly learn their actual velocity & commit accordingly • The outcome of the meeting is the Sprint Backlog.

27. Low tech Sprint Planning Henrik Kniberg

28. Scrum Elements Conchango

29. Artifact 2: The Sprint Backlog • Selected by team at outset of Sprint during Sprint Planning • Each Product Backlog Item will decompose into several Sprint Backlog Items • Granularity in hours… • Estimates and items may change during Sprint as new information is discovered • Simple Excel worksheet can do… • Sufficiently descriptive title • Estimated duration (hours) • Estimated work left (hours) – updated daily

30. Scrum Elements Conchango

31. Process 2: Sprint • Strictly time boxed to two-to-four weeks: it’s far better to fall short than to slip the date • If too much work was selected, reduce scope but focus on still shipping a shippable increment • Ideally Sprint includes design, coding, testing, and documentation for a ship-ready increment • Crisp definitions of “done” • “How will we demo?” • The Product Owner refrains from changing the content of the sprint – team just focuses on delivery • Within the sprint, there are many possible engineering practices (test driven development, pair programming, etc.)

32. Scrum Elements Conchango

33. Process 3: Daily Scrum • A daily team meeting – should be replacing weekly status meetings • Same time every day - $1.00 if you’re late  • Time boxed to fifteen minutes! (Standing up, facing each other in a circle helps…) • The Team and the Scrum Master only “speaking” participants • Three questions for each team member: • What Sprint Backlog Item are you working on? • aka “What did you work on in last 24 hours?” • How many hours are left on your current SBI? • aka “What will you have done by tomorrow’s scrum?” • What are your impediments? (blocking issues) • aka “What will hold you back in the next 24 hours?”

34. Process 3: Daily Scrum • For synchronizing team, not problem solving • Goal is to move team/project forward to delivering on the commitment of the sprint (demo of shippable product increment) • Identify obstacles that must be removed • May follow daily scrum with problem-solving meeting involving only relevant team members • End of daily scrum: review the Sprint Burndown Chart • Extremely visible reminder of where the team stands relative to the commitment it has made • Motivates team to self-organize so as to meet the goal…

35. Scrum Elements Conchango

36. Artifact 3: Sprint Burndown • The Sprint Backlog represents a commitment to a given set of business scenarios (product backlog items) to be delivered/demoed at end of Sprint • It represents an estimated amount of work (in ideal hours) to complete • During the sprint, the ideal would be linear decline in work remaining with each day… • But often SBI estimates are wrong • Impediments arise / Unexpected tasks are discovered • The team needs daily view of the velocity to manage to the sprint commitment

37. Artifact 3: Sprint Burndown • Updated after each Daily Scrum • Primary (sole?) status communicator during Sprint • Can create with Excel, or maintain on flip chart paper

38. Managing Sprints low-tech(Henrik Kniberg)

39. Scrum Elements Conchango

40. Team Element 2: Scrum Team • Self-organizing • Encourage a forgiveness-later-over-permission-now culture when it comes to delivery of business value • Goal is cross-functional team, shared code ownership • 4-9 team members • Team is responsible for selecting and committing to work within a Sprint

41. Scrum Elements Conchango

42. Team Element 3: Scrum Master • The Scrum Master is responsible for: • Success of Scrum in the team & organization • Establishing (& facilitating) Scrum practices and rules, shielding the team and removing obstacles • Representing management to the team & vice versa • Increasing the probability of success by helping the Product Owner select the most valuable product backlog - and helping the Team turn that backlog into functionality

43. Scrum Elements Conchango

44. Process 4: Sprint Review (Demo) • Team presents to management, customers, users and the Product Owner the product increment that has been built during the Sprint • All product backlog items selected for Sprint are included in the demo • Afterward, product backlog might be re-arranged, or decision made to release early (or fail fast) • Product backlog often makes far more sense in light of what has been delivered • Users never know quite what they want until they see initial versions • Business realities or business understanding often change

45. Scrum Elements Conchango

46. Process 5: Sprint Retrospective • Time boxed to three hours. • Team, Scrum Master, and (optionally) Product Owner review the last Sprint • What went well? • What can be improved? • Actionable items are presented to the Product Owner for prioritization as non-functional requirements • We’d be faster with a new build server • We’d have higher quality with more test data • Etc.

47. What is Scrum? 24 hours Daily Scrum Meeting (facilitated by Scrum Master) Backlog tasks expanded by team 30 day Sprint Sprint Backlog Potentially Shippable Product Increment Product Backlog As prioritized by Product Owner Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

48. Other resources • Agile Software Development with Scrum • Ken Schwaber & Mike Beedle • Agile Project Management with Scrum • Ken Schwaber • http://tinyurl.com/tfsscrum (Scrum for Team System Process Guidance)

49. Agenda • VSTS & Lifecycle Management • Whirlwind Scrum Tour • Conchango Scrum Template • eScrum Template (from Microsoft) • VSTS Lightweight Scrum Template (brief)

50. Conchango Scrum Template • Where: http://www.scrumforteamsystem.com • How: Run installer as the “tfssetup” account • Very little config needed; see portal for admin • What: • Work item types, work item queries, reports, and Sharepoint portal customization to support Scrum!