TFS as perfect tool for Scrum (Part 4) – Sprint

This is the fourth part of the series TFS as perfect tool for Scrum. The series is based on my session that I presented at Microsoft TechDays. You can find more introduction in part 1

The agenda for this series is:

1. Introduction in Scrum and TFS

2. Using TFS for grooming your Product Backlog

3. Using TFS in Sprint Planning

4. Using TFS in your Sprint

5. Using TFS in your Sprint Review and Retrospective

Today, Part 4 – Sprint

^{Disclaimer: Within these series I talk about backlog grooming a lot. Nowadays this is known as backlog refinement and refining. Where grooming is used, you can replace that with refinement.}

Part 4 – Sprint

When sprint planning is done, it is time to get to work. The sprint starts. During the sprint the team focuses on the Product Backlog Items that were selected during Sprint Planning. The team made a breakdown in tasks and this is exactly where to start working on. Every day the team comes together during their Daily Standup meeting and tell each other how they are doing. The three questions that need to be answered are:

• What have I done yesterday?
• What will I do today?
• What keeps me from doing my work?

They pick up tasks one by one. During the sprint the team updates the Product Owner and shows the intermediate results. When all tasks of a specific PBI are done, the Product Owner validates the Acceptance Criteria, validates the Definition of Done and “stamps” the PBI as “done” when all of these criteria are met.

Basically this is what a sprint contains. However, what most teams forget is that there is always the next sprint. As I described in (Part 2 and Part 3) grooming is a constant activity that needs to be done by all team members. To avoid problems in Sprint Planning, the team members must spent about 10% of their sprint time, looking at backlog items for the next sprint or the next 3 or 4 sprints.

It is also very important that all activities are planned during a sprint that needs to be done to meet the Definition of Done (more about this later in this post).

Challenges during the “Sprint” phase

So basically, we need to do 2 things within the sprint. Do all the work that needs to be done according to the Definition of Done, and put some time into backlog grooming. What these activities are, varies amongst many different development teams, but the funny thing is, Scrum does not say anything about how to do this development. A lot of techniques, methodologies and tools are mentioned when talking about Scrum, but actually these are all “Agile practices”. For example practices like eXteme Programming (XP), TDD, Build Automation, Continuous Integration etc. are great to use within your Scrum team, but it is not Scrum.

This graph has a great visualization of various agile practices and has some nice explanations as well (http://guide.agilealliance.org/)

So if we take a look at the challenges we see during the sprint phase, we mostly see challenges about how we need to do certain things.

• How do we monitor progress?
• Where do I put my test cases?
• How can I make sure testers test against the latest build?
• How can I support multiple feature teams?
• How do I ensure quality?
• Etc.

The good news is, Team Foundation Server was built with this stuff in mind so keep reading. Before we dive into it, let me first explain a little bit more about the Definition of Done and Ready.

Definition of Done

The definition of done is a very important aspect of Scrum. It describes, in simple to understand language, every single criteria that needs to be met before a Product Backlog Item can be set to done. There must be an agreement on the Definition Of Done by the Scrum Team (so including Product Owner) and, if you have multiple scrum teams, by all Scrum teams. You can compare the Definition of Done with your Quality Bar. What do we need to do before we mark something as “done”. Examples are:

• Acceptance Criteria of Product Owner are met (this is nr 1 on DoD ! Always !)
• Code is checked in
• Code is Unit Tested
• Code Coverage is > 60%
• Functional Documentation ready
• Deployed to Test Environment
• Etc. etc

The more mature your Scrum team becomes, the larger the DoD might become. When your team runs smoothly, you can decide to add an item to the DoD. Of course, your velocity will change after this. The number of Story Points that you can do within a sprint will have a different weight because you do more. When adding to the DoD, velocity will probably decrease. You can find a great starting checklist here.

Definition of Ready

Definition of Done is a great way to have one central and clear understanding about when something is done and can be delivered. The same technique can be applied for the grooming of Product Backlog Items. When it comes to this grooming we can create a Definition of ready. One central and clear definition about the things that need to be done before a Product Backlog Item can be picked up by the team.

Use Team Foundation Server

Team Foundation Server has started mainly as a tool for development teams. So the sprint is the stage where TFS has a lot to offer. Let’s take a high-level look at the activities that the development team does during a sprint.

• Pick up a task
• Write code
• Perform Code review
• Check Code Quality
• Check-In Code
• Deliver code to test
• Write Test Cases
• Execute Tests
• Run Builds
• Monitor Progress

Although almost everything from this list has only little to do with Scrum, TFS is the perfect tool for it.

Pick up a Task and write code

With the Task Board in TFS, it is very easy to assign a task to a developer or to yourself and “show” that the task is in progress. By simply putting the task into this state and putting your name on it, the task becomes yours.

When using Visual Studio 2012, you can see this task in the My Work tab of Team explorer, to easily associate this with the code you have just modified (http://msdn.microsoft.com/en-us/library/hh543900.aspx#check_in)

Perform Code Review and Check-In

When code has been written, it is always a good practice (and maybe part of your Definition of Done) to have a Code Review performed by one of your fellow developers. In TFS / VS 2012 there is a baked in Code Review engine that allows you to easily request Code Reviews and track this within Team Foundation Server. This Blog Post shows a nice walkthrough.

Check Code Quality

There are many tools built in Visual Studio (Premium and Ultimate) that help developers to have better Code Quality. Many of these tools can also be integrated into your automated build process and information from these tools can be extracted from the data warehouse to use in reports.

A quick list of the best tools

• Code Clone Detection – Searches for duplicate code in a very smart manner
• Code Metrics – Measure complexity and maintainability of your code
• Code Profiler – Checks your code for memory and performance leaks
• Static Code Analysis – Performs a code check based on standard rules
• Unit Testing / Coded UI Tests /Code Coverage – Unit test framework
• Fakes Framework – Mocks and Stub possibilities

Check-In code and deliver code to test

Obviously source control is something you can do perfectly with TFS. When having multiple scrum teams, you can benefit from the branching possibilities within TFS and isolate sources from multiple teams and releases.

When creating a branching structure like this, you can merge your code to a DEV-MAIN (DM) branch which is an integration branch of 2 teams. Testers can work on this branch to perform integration tests during the sprint. For more information about branching, take a look at the branching guidance on codeplex.

Write Test Cases and Execute Tests

Testing is an essential part of your sprint. Do not wait with testing, but make the tester part of your sprint. With TFS 2012 (starting from update 2), the tester has the possibility to create and run its tests from the web browser. This gives a lot of flexibility. Because you relate test cases to Product Backlog Items, traceability is automatically created.

Here you can find more information about using the Web Test Case Management in TFS 2012 .

Run Builds

Another thing that is often connected to Scrum is automated Builds. And indeed, it is very important to have your builds automated. Because you develop in short-term sprints, all the time is valuable. When you can automate the builds, it means you’ll have more time to do other work. Besides that, the build is your daily sanity check around your code.

Build management is part of Team Foundation Server.

Monitor Progress

Because everything is centralized within Team Foundation Server, it is easy to monitor progress. Burndown charts, Release burndown charts, Test Reports, Build Reports. All of this is generated for you automatically. Because you can link artefact to each other, you can have very rich and detailed reports about what you are doing and have done. When the default reports are not enough you can always create your own report. Follow my Custom reports series about this subject.

Conclusion

The sprint is mainly about doing the work defined in grooming and planning sessions. Scrum does not really say anything about how you need to do the work. However, there are a lot of Agile practices that fit seamlessly to Scrum. Team Foundation Server is a very robust platform that offers you everything to support a full-blown software factory. Requirements, Coding, Reviews, Source Control, Test, Build Management. Everything is delivered out of the box with TFS and integrates perfectly with your Product Backlog Items and Tasks. Besides that, TFS delivers you the information you need automatically when you manage all of this within TFS.

Let me quickly review the challenges that I often hear to see if we addressed it all.

• How do we monitor progress?
  • When using work items in TFS and keeping track of this, burndowns are automatically generated for you. The various agile boards helps you visualize all of this
• Where do I put my test cases?
  • Test Cases are part of your requirements and are centralized just as all other work items. By using the Test clients (web or desktop) testers can directly start testing and integrate with the rest of the team
• How can I make sure testers test against the latest build?
  • By using the integrated build engine, automated builds can be created and even deployed. Testers can pick available builds when doing tests and log bugs against these builds.
• How can I support multiple feature teams?
  • By using the powerful branching capabilities of TFS you can support the most complex scenarios like feature teams.
• How do I ensure quality?
  • Visual Studio and TFS deliver a large set of tools to ensure quality. Because most of these tools can report to the TFS Warehouse reports can be created from this as well.

The sprint is where work is done. Use Scrum to define what needs to be done and use TFS and Visual Studio to define how it needs to be done !

Resources

• Definition of Done – http://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done
• 10 Point DoD Checklist – http://www.allaboutagile.com/definition-of-done-10-point-checklist/
• Velocity – http://msdn.microsoft.com/en-us/library/vstudio/ff731575.aspx
• Definition of Ready – http://systemagility.com/2011/05/17/definition-of-ready/
• Improving User Stories with DoR – http://www.boost.co.nz/blog/agile/definition-of-ready/
• Subway of Agile practices – http://guide.agilealliance.org/subway.html
• Guide to Agile practices – http://guide.agilealliance.org/
• Using the Task board – http://tfs.visualstudio.com/en-us/learn/using-your-taskboard.aspx
• Code Review with TFS 2012 and VS 2012 – http://chamindac.blogspot.nl/2013/04/code-reviews-with-tfs-2012-and-vs-2012.html
• Branching Guidance – http://vsarbranchingguide.codeplex.com/releases
• Web based Test Hub in TFS – http://blogs.msdn.com/b/visualstudiouk/archive/2013/02/05/web-based-test-hub-in-tfs-update2-tfs2012-2-and-team-foundation-service.aspx
• Build Management in TFS – http://tfs.visualstudio.com/en-us/learn/setup-ci-build-in-vs.aspx
• Custom Reports in TFS – https://osnabrugge.wordpress.com/2012/02/22/using-custom-reports-in-tfs-part-1-introduction-in-tfs-data/
• Quality tools in Visual Studio – http://msdn.microsoft.com/en-us/library/dd264943.aspx