How to use Scrum with TFS and also MIcrosoft Project

Question

I am not new to Scrum neither I am new to Microsoft Project nor TFS. In the past On-Premises I was able to use Microsoft Project with team foundation server, but without SCRUM, it was just waterfall, in TFS we had connected the tasks, and the developers submitted their timesheets and it was easy to track the real time on the tasks.

Now, I am not using TFS anymore but Visual Studio Online with the SCRUM template, I know SCRUM well and we can do project management easily with VSO.

However, the question comes here, as we are a Software Development Company, the task board and pbi board its an internal tool, for the stakeholders they usually want to see the TASKS/Iterations and the percent done, they also want to see if the tasks are taken more time than the initial estimation.

How can we do that with Microsoft Project and at the same time use VSO with the scrum template?

Answer 1

Get your stakeholders to monitor Scrum metrics

You said:

...the stakeholders they usually want to see the TASKS/Iterations and the percent done, they also want to see if the tasks are taken more time than the initial estimation.

The very reason why we switched from Waterfall to Scrum is because software development is not a predictive process. Developers run into unforeseen problems and Product Owners want to be able to make mid-course corrections. Scrum uses an adaptive process to handle such chages. From the Scrum Guide:

If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed.

So, the stakeholders should not be hung up on following the plan. Remember the Agile Manifesto values "Responding to change over following a plan".

Senior leaders of the development organization should be monitoring team velocity and help to improve that, for example:

1. Remove organizational impediments that are preventing the dev team from increasing velocity.
2. Train dev team on technologies that are identified as knowledge gaps for the team.
3. Coach and mentor team members who may be slowing the team down with poor quality code requiring heavy review and rewrite.

Product Management stakeholders should be focusing on the release plan and roadmap and looking for ways to deploy code to actual users early so that valuable feedback can be received sooner.

Answer 2

I have been searching the same topic and trying to used SCRUM with Visual Studio. I came across This guide provided by Microsoft to use Agile approaches with Visual Studio. They changed Visual Studio Online to Team Service and you can use it within premises or on the cloud. In that provided link you will find Ideas and steps about using the Team service with Agile, Scrum and Kanban. I hope you find this helpful.

Answer 3

The Scrum template is a bit messy. TFS ^{*The management tool, not the VCS} is basically made to be everything to everyone and the Scrum template leaks that. There are a lot of features the aren't going to be helpful.

Hour estimates on tasks are not helpful. Stories are things we estimate (hopefully in points not hours). Tasks are a simple organisational tool to facilitate cooperation on stories. They can to some extent be populated up front, but tend to emerge from the work. The predictive power of Scrum comes from the evidence based feedback loop of measured velocity. We can't use this evidence in the precise estimates of tasks. We have to let go of our desire to do fine grained planning (which never worked anyway). In fact, the fact management is so interested in these suggests it's a dangerous vector for micro-management (I'll bear that in mind in future). TFS includes hour estimates, I would set them all to 1.

Completed stories are the measure of delivered value Pay attention this this instead. You may need to run your own numbers and make your own charts. If your objection sounds like "but midway through the sprint we don't have anything done so it looks like we haven't made progress", work on minimizing your WIP. If your stories are too large it will also give you problems, etc. It's really a great metric for exposing process problems.

I've mentioned micromanagement above. You need to focus the business's attention on the value you're delivering. This means stories. Here's a great article, Do you want Crappy Agile?, on metrics by Ron Jeffries (one of the founders of XP).