Urban Turtle's blog

Urban Turtle users often ask about why they do not have access to the real-time hour burndown introduced in version 3.5. While somewhat technical, the reason is actually pretty simple. Urban Turtle relies entirely upon Team Foundation Server to store any information regarding your project. As you probably know, classification in TFS is based on iterations and areas. Besides the name of the classification node itself, there is no other way to store iteration and/or area metadata. To work around this limitation, popular process templates such as Visual Studio Scrum 1.0 and Scrum for Team System have introduced the Sprint work item type definition. The sole purpose of this work item is to store information regarding your team sprints. Among other things, it lets you specify start and end dates, which are obviously a prerequisite to create a hour burndown chart.

The MSF Agile 5.0 process template does not specify such a work item type. Fortunately, Team Foundation Server is designed to let you customize your project’s template to better reflect your business process. It is therefore rather easy to add a Sprint work item type to an existing MSF Agile 5.0 project. In this blog entry, I will show you how to import the Sprint work item type definition from Visual Studio Scrum 1.0 into an existing MSF Agile 5.0 project.

Prerequisites

Sprint work item type definition
You will need to know the location of the Sprint work item type definition from the Visual Studio Scrum 1.0 process template. If you haven’t done so already, you can download this process template from the Visual Studio Gallery on MSDN. If you install the process template in the default path, you will find the Sprint definition file (Sprint.xml) under ‘C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\Process Template\WorkItem Tracking\TypeDefinitions’.

witadmin.exe
Importing a work item type is done through the use of a command-line utility known as witadmin. You must first locate this utility on your computer, preferably on your server hosting Team Foundation Server. If you have Visual Studio 2010 installed, you should be able to launch a Visual Studio Command Prompt from the Start menu, which will allow you to skip searching for the executable file itself. Otherwise, the file can be found by default (on an x64 installation) under ‘C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\witadmin.exe’.

While this article describes how to use the witadmin utility, you could choose to use the Team Foundation Server Power Tools which Mathieu refers to in his Approval feature with MSF Agile 5.0 article.

Importing the Sprint work item type

1. Start by launching a Visual Studio command prompt (if available) or a standard command prompt. If the former is unavailable to you, make sure to navigate to the location of the witadmin utility. Check the prerequisites above to help you locate it.
2. Launch the witadmin utility by specifying the following arguments:

   /collection: The URL of the Team Foundation Server collection that contains the MSF Agile 5.0 project.
   /p: The name of the MSF Agile 5.0 project
   /f: The path of the Sprint.xml file, enclosed in double quotes.

   For example, using the arguments that match your environment, type the following command and press ENTER:
   witadmin importwitd /collection:http://localhost:8080/tfs/DefaultCollection /p:Agile /f:"C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\Process Template\WorkItem Tracking\TypeDefinitions\Sprint.xml"


3. If all goes as expected, the following message will appear: “The work item type import has completed”.

Configuring Urban Turtle to recognize the Sprint work item type
Urban Turtle uses what we call Configuration Mapping Files to deal with differences between process templates. You can create your own mapping file and configure your project to use it. By default, the mapping files can be found under ‘C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Access\Web\UrbanTurtle\configuration\project’. We must advise against editing one of the default files as these get removed when uninstalling the application.

1. Start by copying the MSF Agile 5.0.xml file, and open the copy using any text editor. Locate the
   TemplateConfiguration element at the top of the document and change the Name attribute to something like “MSF Agile 5.0 – Burndown”.
2. For Urban Turtle to recognize the new Sprint work item type, you must add an entry in the mapping file, telling it exactly what work item type represents a Sprint. It could be any type, but it must have fields to contain the start date, end date and a description (or sprint goal). Since we are using the Sprint work item type definition from Visual Studio Scrum 1.0, you can copy the required configuration from the default mapping file for this process template and append it to the Features element.
3. The last step required is to configure your project to use the new mapping file. This is done through the Configuration page in Urban Turtle, accessible from the Configuration option under the Project menu.
   
4. Simply select the new “MSF Agile 5.0 – Burndown” and then click the Apply button to save your selection.
   

Using the Hour Burndown
Displaying the Hour Burndown requires you to create a Sprint work item in the selected iteration. This is made very simple by Urban Turtle just by clicking the Sprint Details icon on the iteration box.

Once you have specified start and end dates for your sprint, you can display the Hour Burndown. First, make sure the iteration is selected in the iteration panel and then click on the Burndown button on the toolbar.

Voilà, a real-time Hour Burndown with MSF Agile 5.0!

As you can see, just about any feature that is not available out of the box with your process template may be enabled by customizing your project and creating a custom configuration mapping file. Some of you may recall that we had already shown how to enable the Recycle bin functionality for MSF Agile 5.0 projects. With these features enabled, MSF Agile 5.0 users have no reason to feel left out when using Urban Turtle!

Early in the design of Urban Turtle, we envision a product so simple to use that one would use it without having to consult documentation. We have partially achieved this goal but we believe we can do better (and, we plan to do better but without violating our motto which is “less is more”). In this connection, stay tuned for the upcoming major upgrade of Urban Turtle (version 4.0).

However, in the meantime, there are training needs that remain to be met. For example, simple questions such as how to install Urban Turtle or how to launch Urban Turtle using Team Web Access are recurring themes. In addition, over time, we discovered that explaining how Urban Turtle support Scrum needs to be more explicit. That’s why we have created a “Quick Start” section on our website.

This getting started section provided short screencasts (2-3 minutes videos) to answer these recurring questions. Because it allows getting “inside” the product to show how small parts work, screencasts work particularly well to a highly-technical product such as Urban Turtle.

On the “Quick Start” page you will find the following screencasts:

• Installing Urban Turtle
• Launching Urban Turtle
• Explaining Scrum in less than 120 seconds
• Grooming the backlog with Urban Turtle
• Planning the Sprint with Urban Turtle
• Tracking day to day work with Urban Turtle

Furthermore, this is where you can download documentation about how to configure Urban Turtle. Learn about the hidden gems that you can access only through the global settings file.

Here is the link to visit the “Quick Start” page: http://urbanturtle.com/quickstart

Our customers know that each month sees another release (8 months, 8 releases). We just release Urban Turtle version 3.7 and, although this is still in beta, this version include built-in support for Scrum for Team System 3.0 process template. We know this is a popular template and we hope you will want to try it and send us suggestions. Do not forget that the best way to make a suggestion is by sharing your idea on our community site. Through the community site, others can vote for your ideas and increase their priority.

http://community.urbanturtle.com/urbanturtle#idea

By design, Urban Turtle can work with any TFS process template, whether it is a widely available template such as Microsoft Visual Studio Scrum or a custom template built specifically for your organization. Out of the box, for compatibility with existing process templates, Urban Turtle supports MSF Agile 5.0 (French and English), Microsoft Visual Studio Scrum 1.0 and Scrum for Team System 3.0.

Support for TFS process template is based on external configuration mapping files which can be managed by administrators. For instance, adding support for your own process template only required to create a new mapping file and didn’t involve any changes to the application itself. Anybody who understands XML can do this. The XML configuration mapping file is located at:

%TFS INSTALL DIR%\Application Tier\Web Access\Web\UrbanTurtle\configuration\project

Although we have yet to release formal documentation for the mapping files, we do provide support should you wish to customize Urban Turtle to better fit with your current process template.

Urban Turtle is pleased to announce it is partnering with a select group of training organizations offering the Professional Scrum Developer (PSD) program. These organizations are Accentient, Pluralsight, Pyxis and SSW. Partnership involves a credit promotion for Urban Turtle and visibility of partner’s classes.

Professional Scrum Developer courses teach students how to turn product requirements into potentially shippable increments of software. Scrum traditionally avoids providing guidance for engineering practices. This course fills that void by addressing what developers do with the remaining 7 hours and 45 minutes of their day after the daily Scrum meeting. Classes are exercise-driven, where students work in teams and develop “done” increments from product backlog items. Each class is five days long, and classes can be either public or private.

All Professional Scrum Developer courses cover three main topics:

1. Scrum. PSD courses cover Scrum Fundamentals like Scrum roles, artifacts, and timeboxes. The course simulates being part of a Scrum team to expose students to these concepts in action. Students learn how to work as part of a Scrum team, which requires them to understand techniques for self-organization. At the end of the course students develop skills in identifying and eliminate typical types of Scrum team dysfunction.
2. Tools. PSD courses teach students how to leverage different development tools to employ Scrum practices. PSD .NET courses are taught in the context of Visual Studio 2010 using the Microsoft Scrum process template and add-ins such as Urban Turtle. Students learn how to map specific tool features and functions to the general Scrum practices they must use to be effective team members.
3. Practices. PSD courses cover all of the technical practices that team members need to successfully implement and ship functionality. These include coding practices like test-driven development, continuous integration, and refactoring; architecture practices such as emergent architecture and evolutionary database development; release management practices like planning, requirements definition, and deploying, and quality assurance practices from defining “done” to pair programming to version control to acceptance testing.

Aaron Skonnard, founder of Pluralsight explains why they joined this Urban Turtle initiative:

“Any initiatives that eases adoption of proven engineering practices with Microsoft technologies will always gain support from Pluralsight”

We asked Adam Cogan, Chief Architect for SSW and Microsoft Regional Director, who teaches the PSD .NET course all around the globe, what his thoughts on Urban Turtle were. He said:

“Mario one of the high value take-aways the students tell me they get, is seeing some of the great third party TFS tools in action. That’s why I ensure I demonstrate Urban Turtle, so they see Team Web Access providing awesome value, and it eases adoption of Scrum with the Microsoft Visual Studio Scrum process template”

Then we have Richard Hundhausen, Accentient’s president, who in cooperation with Microsoft and Ken schwaber, created the Professional Scrum Developer .NET training course says

“I has not yet met a certified PSD trainer who did not want to be listed as a friend of the Turtle”

When registering students for a PSD .NET course to get up to 100% off your Urban Turtle license cost, all you have to do is register for one of the training sessions listed here http://urbanturtle.com/?item=professional-scrum-developer. Make sure to mention your Urban Turtle license when registering. Your discount will be applied to your training fees. For more information on the curriculum of the Professional Scrum Developer program visit http://www.scrum.org/psd-net-syllabus/

For those of you planning to start a new project with the Visual Studio Scrum 1.0 Process Template, Mickey Gousset just write a good paper in the Visual Studio Magazine. He introduces the new Microsoft Scrum 1.0 Process Template for Visual Studio Team Foundation Server and steps through the installation process.

http://visualstudiomagazine.com/Articles/2010/07/27/Installing-Scrum-Process-Template.aspx

Urban Turtle 3.2 fully supports the new Visual Studio Scrum 1.0 Process Template. Using the index card metaphor with drag-and-drop functionality, it is the perfect replacement for Excel-based planning workbooks.

Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.

Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome!

Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft.

My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog.

Mathieu: Sure, I will suggest him that but I think he also wants to track cost.

Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations.

When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead.

Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:

• Where do we put the time for meetings?
• Do we need to have absolutely all tasks in the sprint backlog?
• When we are pairing, do we do time entries for each of us?
• When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)

And the list goes on. All these questions are a struggle for the Scrum Team and answering them does not help them in creating high value software fast. Therefore, my answer now is: Tracking actual work on sprint backlog item is not part of Scrum. Period.

The reaction I usually get is either “this is impossible in real life” or “you are telling us that a Scrum Team is not responsible for its cost”.

I think that a Scrum Team IS responsible to be aware of their cost and the value they bring to the organization; they are software professionals and therefore they strive to maximize the ROI of their work. The Product Owner is specifically accountable for maximizing the ROI by appropriately prioritizing the product backlog.

The reaction is usually “I don’t get it. You are saying not to track actuals on sprint backlog items and at the same time that the Scrum Team is responsible for its cost.”. Here is the suggestion I usually provide. Most organizations are interested in knowing how many hours their people work to be able to produce the pay checks. Therefore they have a timesheet system where people enter their time. My suggestion is to have time entries per project (much higher level of granularities than the sprint backlog items). Therefore, a team member working on a single project will produce one time entry per period. Timesheet system or not, you should be able to easily query your enterprise systems to know salary costs for a given period. May be you are lucky enough to have a cost tracking system in place that is able to give you the answer to how much expenses directly related to the product development were made during the same period.

My point is that it should be possible to identify the total cost of an iteration and have the Scrum Team track this. Considering all of this, I have a request to make to Microsoft : Add the fields ‘Scrum Team Cost’ (numeric) and ‘Other Costs’ for iterations in the Scrum process template. This will be useful for enterprise Scrum. May be it is not too late to put it before version 1.0 goes final

Cheers,
~françois

In the past, we’ve made claims that Urban Turtle supports virtually any process template. Therefore it came as a surprise to some people when our team said that building support for the new TFS Scrum template from Microsoft would take almost an entire two-week sprint. I’d like to take some time to tell you what we think means to be template-independent and how it differs from building true support for a process template.

Supporting MSF Agile 5.0
Urban Turtle 3.0 shipped with built-in support for MSF Agile 5.0 out of the box. We obviously assume most people using Urban Turtle have chosen this template because of this build in support. This template made it a challenge for us to implement a three-column task board because work items only have one Active state. Items are either active or they’re resolved or closed. Back then, we decided to use the AssignedTo field to determine where the work item should appear when it is active. An unassigned and active task should show up in the To Do column while an assigned and still active task would appear in the In Progress column. It made sense to us as we’re Scrum practitioners and we believe tasks should be unassigned until someone actually starts working on them.

While implementing support for MSF Agile 5.0, we made sure to externalize everything that seemed template-specific, like the state mapping for the task board columns or the stack rank (backlog priority) field. We then claimed to be template-independent, but some assumptions would later turn out to be wrong.

False Assumptions
When Microsoft announced the beta release of their TFS Scrum 1.0 process template, we figured we could quickly create a new mapping file to add support for it. We began analyzing the new template and we realized we couldn’t do it without touching the code base. Honestly, it would have been as easy as we thought but the decision by the Microsoft team, to stay true to the Scrum terminology, turned out to be a blocker for us.

When working on the initial release of  Urban Turtle 3.0, we made the assumption that system fields such as Id, State and AssignedTo would not be configurable. That was a mistake. Microsoft decided not to use the AssignedTo field used to determine who’s working on a task and opt to go with a field named OwnedBy. The vocabulary makes tons of sense but the change made it impossible to use Urban Turtle as it was with the new template.

When basic is not enough
This change was all that was required to build basic support for TFS Scrum with a new mapping file. We could easily define what fields should show up where, what states should appear in the task board columns, etc. We built this basic support within a single day, including refactoring the application code to support configuration for the AssignedTo field. However, we found such basic support to be somewhat lacking.

We started testing the application with the new template and we quickly realized that the state mappings pretty much made the task board impossible to use with Product Backlog Items and Bugs. These two types have the following states: New, Approved, Committed, Done and Removed. We ignored the latter and configured the first three to show up in both the To Do and In Progress columns and mapped the Done state to the Done column. However, the transitions configured between the three active states made us realize that only the Committed state actually made sense in the task board.

We thought that choosing to hide new and approved work items from the task board would cause confusion when users would look at their task board and search for missing items. That’s when we decided to implement two new features to facilitate the state transitions.

New Feature: Approval
Product Owners can now approve PBIs with a single click when looking at their backlog in the Planning Board. This feature can be configured as a state transition in the mapping file and could be used with other process templates. In the case of the TFS Scrum template, we’ve mapped the New -> Approved transitions for PBIs and Bugs to the Approval feature.

New Feature: Commitment
Approved work items still don’t show up in the task board. The task board is used to track work being done during a sprint. The team should never be working on something they haven’t committed to yet. It makes perfect sense with regards to Scrum. We could have implemented this feature the same way we did with the Approval, but while a Product Owner usually approves items one by one, a team commits to a set of PBIs. For that reason, we decided to make this a batch process. We therefore made it possible to commit to PBIs contained in a sprint with a single click, again from the Planning Board. This feature can be customized by defining the state transition that should be triggered when this feature is used.

New Feature: Sprint Details
The last thing we wanted to add to our initial support of  TFS Scrum was a way to manage the new Sprint work item type. This type was defined as a way to work around limitations in TFS regarding Iteration nodes metadata. It defines begin and end dates for the sprint, as well as sprint goal and retrospective details. We’ve made it easy to create and access this work item through the Sprint Details button in the planning board’s iteration list. This button only appears when the Sprint work item type is defined in the mapping, another customizable option.

Beta Release
It has been a mere two weeks since the release of  TFS Scrum 1.0 Beta (Visual Studio Scrum) and we are ready to give you a taste of the support we’ve built for it in Urban Turtle with the beta release of Urban Turtle 3.2. We hope that you will take the time to give it a try and we are looking forward to hearing from you  as we strive to improve the Turtle and accomplish our mission to enable your team to create kick-ass software – fast and sustainably.

There has been a debate in the Scrum and Kanban communities about having iterations  (sprints) or not. I am worried that this blog post will generate flame wars and rants. Thus, there will certainly be some energy that will be lost. My hope is that this post will generate real debates and discussions so we can learn from each other’s opinion.

I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum.

My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments.

When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work.

Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams.

Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints.

I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.

A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.

Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management
.

While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain.

I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal.

Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process.

This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:

1. How people perform correlates to how situations occur to them.
2. How a situation occurs arises in language.
3. Future-based language transforms how situation occurs to people.

I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings.

In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.

Once again the team has committed to a new release Monday morning.

This is the plan for the next trip !

In the first sprint, we will make sure that the Turtle can sprint with the new Team Foundation Server Scrum v1.0 template announced at TechEd on Monday. You can download the new template here. We are really excited that Microsoft has decided to jump in the scrum world!

In the second sprint, we will implement a natural way to filter areas and iterations using a tag concept. You will have the option to put a push pin on some areas and iterations to apply a filter based on those selected and work with a subset of the work items. This will simplify backlog visualization and make sure the team’s focus is on delivering awesome software sprint after sprint.

This will help you doing enterprise scrum and complex project management with the Turtle.

If you want to manage your projects like one big project as suggested by Martin Hinshelwood on his blog, this feature will let you do that with Urban Turtle. I think you will really like this new feature.

Send us your comments on the forums!

Dominic !

In Answering some common questions about Urban Turtle we answer some questions and present some of the orientations we took in designing Urban Turtle.

One of the main orientation is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.

We believe this orientation is what allows us to have a product that installs on the server in less than two-minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.

Help us make our Urban Turtle a Chameleon

Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.

In the release that we have for you this week (June 2nd), we deliver a bunch of enhancements including a productive way to use Areas. The upcoming release will most likely focus on a feature we call Perspective that will allow you to work seamlessly in Urban Turtle on a subset of work items making it a charm to do multi-teams and grouping projects together. We will also focus on enhancing user experience in a couple of key places.

Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.