My Old IIS.NET BlogTechNet Magazine Articles Learn about IIS7 from a book I wrote a few years back!
In my earlier post, I focused on bringing to light that MSF Agile v5.0 vs. Visual Studio SCRUM 1.0 had differences and one was just in their use of terminology. Whether it was user story or product backlog item (PBI) the usage was very close minus one to two differences. Today I’d like to continue this discussion but moving to the next major difference and that is around the tools available to you when you are planning your work, as well as manage your concept of a “sprint.”
For many individuals who are adopting Agile, they often will use various resources to learn the concepts including SCRUM trainings where hands-on instructors teach the concepts of SCRUM. There are some basic resources that I’d recommend to anyone who is seriously interested about learning more about Agile Software Development -
To simplify it, the basis for the two versions of process templates are deeply rooted in these resources. This includes terminology all the way to planning and tracking success which is what today’s post is about – focusing first on MSF Agile v5.0.
The first thing to understand is that MSF Agile v5.0 was released with Team Foundation Server (TFS) 2010 and is a built-in process template. It is built primarily on the concepts outlined in the Agile Manifesto and influenced heavily by Mike Cohn.
The primary differences I will point out about MSF Agile, as it compares to SCRUM 1.0 (covered tomorrow), are the following:
You will notice when, soon after creation of a new project, looking at the default samples & documents is very robust with MSF Agile with a lot of Excel reports along with SQL Server Reporting Services (SSRS) reports. This is shown in the below image -
Beyond that, you will notice that by default the project as been setup with a few “default” iterations for you such as Iteration 1, Iteration 2, and Iteration 3. These iterations are the basis for several very important queries that make the workbooks provided to you work by design. These workbooks will throw an error immediately after loading if you’ve change the name of the iterations or moved the queries.
With that said, managing your product/release backlog in TFS 2010 using MSF Agile v5.0 is rather straight-forward if you understand how to use the tools provided. In this section, I’m going to quickly share with you how to manage your product backlog correctly when using MSF Agile – while later I will contrast this with how Visual Studio SCRUM 1.0 lacks these out-of-box useful workbooks.
Managing Product Backlog using the Product Backlog Workbook
The first thing that most dev managers, or project managers, do is edit the iterations in MSF Agile -
You can now use the User Story WIT or use the Excel workbook called “Product Planning” to setup your backlog. This is how you effectively manage your backlog either using user stories in MSF Agile v5.0.
The most important step for any project team is to get past backlog and on to the real work. I’m not downplaying the importance of having a healthy backlog but a backlog is just that – a backlog. It doesn’t equal work that will help user stories become real software components that drive your business. Because of this, the next major step using MSF Agile v5.0 process templates is to utilize either tasks, test cases, etc. to setup iteration work.
The MSF Agile process template offers a wide-array of tools to setup your iteration. The key ways are the following:
For the purpose of this post, I’m going to focus on number 2 since that is the primary contrast against Visual Studio SCRUM 1.0.
MSF Agile v5.0 projects are automatically created with Excel workbooks in the [Documents]\[Project Management] folders that really help you do you planning for the iteration. Iterations are made up of user stories, tasks, and test cases that all have “planning” pieces to them. These planning pieces allow you to not only Story Point the effort (user story) but also give estimates on the amount of work the activity (task, test case) will take. This is human effort.
The effort is then easily tracked with the TFS built-in fields Remaining Work & Completed Work. This allows you to effectively plan base on capacity using holidays/training (interruptions) and effective hours committed per day.
This is really nice! As you can see each person is given hours/day and then capacity which tells you that you need to remove work from the sprint. You will quickly find yourself struggling with this when you utilize Visual Studio SCRUM 1.0 as there is no capacity meter when doing planning unless you do it yourself!
For more detailed information on using the Iteration Backlog workbook, please see this blog posts -
Besides this, you might find it very useful to also do the same level of tracking if you use the Bug WIT and in this post I explain how to change the Bug WIT to track remaining & completed work for tracking purposes.
The next step is to understand how you can effectively track your progress in MSF Agile v5.0 projects. This is a bit more tricky and I’ve spent a lot of time on this subject in past posts so this section is really going to point out posts I’ve made regarding the subject. However, where applicable, I will share what’s important for the purpose of this post.
By default, you will take advantage of built-in reports – either Excel or SSRS – to track your progress within an iteration. The challenging piece with MSF Agile v5.0 is that you have *no* data stored within TFS for the project start date & end dates. This data, instead, is stored in a Excel workbook called Iteration Backlog in SharePoint. Or, you can also provide the data in a report that places timestamps for begin & end in your queries and builds the “picture” for you.
Utilizing Excel Iteration Backlog Workbook
In this post, I shared the Soup-to-Nuts on how to effectively use the capacity planner & interruptions to learn how you look as far as capacity. You should use this a learning guide on how to effectively use this without any issues to plan your iterations in MSF Agile v5.0.
Utilizing SSRS Reports – Burndown & Burnrate to track progress
The other option is to utilize the built-in SSRS Reports called Burndown and Burn Rate that is stored in your project under Reports. Even though this is stored in Visual Studio, these reports are stored in SSRS and any report created at the path [Project Collection]\[ProjectName]\Project Management. There is also dashboard folder that has some specific reports that vary slightly (IsDashboard parameter set to True) to enhance the default dashboard view that is created with TFS.
By default, the burndown and burn rate reports are scoped to dates around on month or so out. They are not, unfortunately , scoped to the iteration you are interested in. To effectively alter reports to show iterations with specific dates that match the iteration, you would follow the instructions I outlined in this post (ignore the title).
This is nice to have to follow your iterations but as you will quickly find out it can be a time consuming activity if you actually have fast iterations, such as 2 weeks. You will find this experience much different in the Visual Studio SCRUM 1.0.
One of the key concepts that you will learn in Agile is to create repeatable processes while always focusing on getting better. The way that you can focus on getting better is to utilize Retrospectives per iteration/sprint. In MSF Agile v5.0, the method you use to track your retrospectives is to use a default template provided to you in your project SharePoint. This is very important – it is not stored in TFS but instead in a document library.
The default retrospective template is stored in Documents – Samples and Templates as shown here -
The retrospective documents, although important to team improvement, are not stored in TFS rather they are stored in the project SharePoint document library. This is the case only for MSF Agile v5.0.
The purpose of today’s post is to really help project leaders, and even developers & testers understand the differences between the planning tools for MSF Agile vs. SCRUM 1.0. I will soon compare and contract this in a second post tomorrow that focuses on Visual Studio SCRUM 1.0 – these two posts are so long I’m breaking them up to help keep things clean.
The key aspect of any successful software development project includes some level of planning – you might be successful in the short term with limited planning but in the long run you will fail. This includes in doing release planning (for another post on another day) but when it comes to getting work done in a ordered, stack-rank approached you have to utilize the tools available to you.
Out of the box, MSF Agile provides you a lot of nice features including the Microsoft Excel Backlog workbook along with Sprint Iteration Backlog workbook. Beyond that, MSF Agile provides a nice set of Excel & SSRS reports around project management that I discussed.
I hope today’s post has been helpful. In my next post, I will focus some details Visual Studio SCRUM 1.0 and make sure that you are aware of the nuisances & differences!
Chris, Thank you again for the wonder post. MSF Agile seems to have a lot of quick helpers built in to better track the progress.
I must agree with previous poster, this article was great. Actually best blog post ever!
I'm in a stage right now to try to decide and help with decision to projects why use this process template or take that. And one thing i dont wanna do is trying to change afterwards templates if we choosed wrong in first place... that is such a mess.
Keep up this good work! :)
I'm glad you enjoyed the post! MSF Agile does have a lot of investments to help track progress though it is missing some key things that make it harder to use (e.g. not start/end date). I am glad this helped!
Hey Mr Weiland-
I'm glad that you found this post useful. I hope the entire series helps you make the right decision, whichever way you decide to go. As you mentioned, it is not fun at all to move from one process template to another.
Very well written article. Thanks for Sharing