Urban Turtle's blog

We told you it was on the backlog. We told you it was rising in priority. We told you we wanted to see it included in a future release. We then told you we were working on it. For real even! Well, after years of asking, the Urban Turtle team is proud to present to you version 3.15, including its flagship feature: custom task board columns! No longer will you be constrained to a three-column layout. Urban Turtle has freedom written all over it!

Custom Task Board Columns
With version 3.15, Urban Turtle now reads the column definitions from the configured mapping file and displays the corresponding number of columns. It is actually very simple to add columns, since we’ve retained the same configuration file format as the previous versions. In the previous versions, there were only three column sections in the configuration file and you weren’t able to add new ones. I’m pretty sure some of you have tried this, to no avail. Now, adding a Read To Test column is as simple as making this change to your configuration file:

Your process template must already define a Ready To Test state for this work. The configuration mapping file allows you to map your process template to Urban Turtle features, but it does not change your project’s template. We’ll try to have a blog post ready describing how to add a Ready To Test state to the Task work item type in the Visual Studio Scrum 1.0 process template. You can however get a head start by reading through this blog post which introduces the mapping files and links to other blog posts that describe how to enable some features in Urban Turtle by editing your project’s process template.

Story Point Burndown Chart
Another oft-requested feature is a burndown chart in story points and we finally delivered the goods.

This new chart is very similar to the Hour Burndown, calculating the sum of story points at the end of each day of the selected sprint, excluding stories considered done, meaning those in the state mapped to the Done column of the task board. The exact field whose sum is calculated is actually the field configured as the Story Points field in the Statistics section of the configuration mapping file.

Duplicate Work Item
The Quick Add feature has proven a hit following the release of Urban Turtle 3.14. We have decided to follow through with a Duplicate feature which allows you to, wait for it, duplicate a work item in a single click! This is especially useful during sprint planning when you need to create common tasks for all your product backlog items. Now you can simply create it once, duplicate it as many times as you need, and quickly move it to their new parent backlog item. Here’s a short video of the duplicate feature in action:

Improved support for lower resolutions
Soon after the release of Urban Turtle 3.14, we started receiving reports of card wrapping issues on the task board. This was due to our strict adherence to our chosen minimum recommended width for Urban Turtle which is 1280 pixels. We quickly decided to remedy this issue in the next release, and we’re proud to announce that Urban Turtle will now play nice with lower resolutions, especially the popular 1024×768 resolution used on many projectors.

This is a very exciting release for the team and we hope that you will agree. As usual, we recommend that you upgrade to the latest version (Don’t forget to refresh your browser’s cache!). I also invite you to voice your opinion on this feature or ask for help on our community support site! We look forward to your feedback.

A few customers have inquired about how Urban Turtle handles being set up in a load balancing scenario. I thought it would be interesting to describe the current state of affairs on our blog to share with the rest of world.

When it comes to load balancing, there are some issues that you should be aware of. These are described in the following topics on our community support site:

• Urban Turtle on load balanced application servers?
• Setting up Urban Turtle on multiple TFS app servers.

Scott Hanselman has a great summary of some of the things that you should take under consideration when dealing with multiple web servers. In most cases, the first scenario is really the one that applies to us: Urban Turtle uses an in-process session state which requires a particular load balancing setup to work properly. The problem is caused by client requests (user actions in the application, such as selecting an iteration) being processed by different servers. Imagine that the user clicks on the Planning board tab. This request is processed by Server A which was picked by the Load Balancer. Then, the user selects an iteration. This request is handled by Server B, which the Load Balancer picked because Server A was determined to be busy. Urban Turtle stores the selected iteration on Server B, which Server A is unaware of. Therefore, when the user requests the Hour Burndown, if Server A processes this requests, it will not be aware that another iteration was selected and will return the Hour Burndown for the wrong iteration, causing confusion.

The first solution would be to configure sticky sessions/connections or client affinity. The term used may vary depending on your load balancing application vendor. This basically ensures that all requests from the same client are routed to the same server. Thus, the client always uses the same session state and therefore, the same Urban Turtle application settings.

Another solution would be to use a State Server. This is something that you may already have set up for other applications in your infrastructure, but I wouldn’t know about that. In this scenario, session data is stored in another process, on another server and is shared by all web servers in the load balancing environment. Urban Turtle has never been tested in such a scenario. It requires that all data stored in the session state be serializable and I cannot guarantee this as Urban Turtle was not designed with this in mind.

Here are some links regarding load balancing and session state:

• Load Balancing and ASP.NET
• Understanding session state modes + FAQ
• How to keep user requests on the same server when using IIS NLB?
• Configure a State Server to Maintain Session State (IIS 7)

I hope this helps. If you have any questions, please do not hesitate to contact me.

Once again, Team Urban Turtle is quite proud to announce the release of Urban Turtle 3.14. Featuring updated visuals and the ability to fill a backlog or decompose a product backlog item in seconds, we’re pretty sure you’ll be as excited as we are about this new version.

New Design
While strictly an aesthetic update, the new planning and task board design in Urban Turtle 3.14 was also aimed at improving the visibility of the boards when displayed using a projector. The original design, albeit attractive on paper, turned the Turtle into a Christmas tree (actual user comments!) when used in the real world. Even though it has always been a concern for us, we chose to concentrate on developing new features since the 3.0 release. This update was long overdue, and this is why we tasked our web guy, Guillaume, to come up with a new look for the application. We’re very happy with the results and we hope you will be too! We can’t wait to hear what you think about it. It may be disconcerting at first, as with any major change, but given time, we’re convinced you’ll find the new look to be quite easier on the eyes. Can’t go wrong with less eye bleeding, right?

Quick Add
We know for a fact that our users tend to avoid round-trips to the Work Item Editor window in Team Web Access like the plague. And with good reasons! It is painfully slow to render and it forces a planning or task board refresh when closed. This is why we try to come up with features that avoid having to go through this window.

Urban Turtle 3.14 introduces the Quick Add section which aims to make the user story/product backlog item decomposition part of your Sprint Planning meetings an actual joy to do. It allows you to add tasks to a PBI in a matter of seconds, without ever going through the Work Item Editor. Simply type in the work item title, press enter and a new work item appears immediately. What’s really cool about this is that you don’t need to wait for the work item to actually be created in TFS. The creation part is all done asynchronously, so you can just continue to type in work item titles and press enter. Combined with the in-place editing capabilities, creating tasks and setting the work remaining is no longer the chore it used to be.

The Turtle is very excited to show its new colors and the speed it has picked up when creating work items. We invite you to update to the latest version and discuss it on our community-powered support site.

So your project has been going along for a while now and several iterations are completed. Your iteration panel is starting to look a little crowded. Maybe something like this:

You start to wonder about how great it would be if you could hide those past iterations so you can focus on the current and future ones. Lucky for you, this Turtle just happens to be wearing a sweater (this is Canada after all) and its sleeves are full of tricks!

There are two possible ways to hide older iterations. The Favorites feature (the stars that you see on each iteration) is the most obvious one to use. Simply click on the star for each iteration that you wish to hide, turning the star grey. Then, click the Apply Favorites button to only show the selected iterations (the ones with the yellow stars). This also works for areas.

However, there is one caveat that you should be aware of. Hiding a large number of iterations using favorites may lead to performance issues as one of our customers has reported on the community. A proposed work-around is to use the Team functionality to hide a part of the iteration tree. You see, teams can be configured to have a distinct root iteration. By default, the project node is the root iteration. If you change the root iteration, the nodes that are not under it will not appear in Urban Turtle. So a recommended solution would be to have a structure similar as the following:

If you make the Current Iterations node the root node for your team, then you won’t see the node Past Iterations or its children. This is a lot faster than hiding individual iterations using the Favorites feature. In Visual Studio, it is possible to move individual nodes. So you could move an iteration that is under Current Iterations to the Past Iterations node when it is complete and it will be hidden from Urban Turtle.

If you look at your own planning board, chances are you won’t find a Team menu as shown in the preceding video. This is because you need to enable it through the global.settings file. For instance, the global.settings file used in this video looks like this:

The documentation for the Team functionality (and the global.settings file) can be found here.

After breaking tradition and our monthly release cycle, Team Urban Turtle is proud to present to you version 3.13 featuring the most requested idea ever!

New Features

• Our planning board has always been agile, but we had it learn some new tricks to make it more flexible than ever. With most process templates, it is now possible to simply drag a work item and drop it anywhere you want. Urban Turtle will take care of figuring the updates required such as removing the current work item link between the item and its parent, creating a new one and prioritizing the work item within its new siblings.
• The iteration panel can now be collapsed, leaving more space for the work items. This was accomplished by inserting the iteration panel inside of the default Team Web Access side-panel. As this is where Team Web Access displays its search bar, users also gain access to search capabilities at the same time.
• With Urban Turtle 3.9, we introduced independent iteration and area settings for the planning and task boards. This change didn’t please everyone, so we decided to turn this itself into a setting. On the iteration and area panel, a pushpin icon has been added. When the pushpin is colored, it is active, forcing iteration and area settings to be retained across both boards. Otherwise, settings are independent.

Improvements

• A few usability improvements have been made to the planning board. Now that the iteration panel can now be hidden, it was obvious we needed to expand work item titles to fill the space. This automatic expanding and truncating of the work time titles is also done when resizing the window. This means that the larger screen resolution that you use, the more you will be able to see of the work item titles.
• A little known feature that has always been present on the planning board is the ability to select multiple work items to drag and drop them on an iteration, an area or the recycle bin. We’ve decided to improve this and highlight this functionality by adding checkboxes on work items. This makes it a lot more obvious that this feature exists. Please note that multi-selection does not apply when reordering work items.We’ve also ported the ability to collapse parent work items from the task board to the planning board.

Fixed Issues

• Users of the french version of the MSF Agile 5.0 process template will be glad to know that we have resolved the issue that prevented adding some child work items. The problem was due to accents in the work item types (such as Tâche).
• We have also fixed an issue preventing moving a work item after the last visible work item on the planning board.

We know that it’s been a long time coming (the ability to change work item links using drag and drop has been requested over a year ago!) and we invite you to download the latest version. Your feedback has always been invaluable to us and we’re very excited to hear what you have to say about this new release. While we already have ideas in mind for the next release, your feedback may still steer our decisions. Don’t hesitate, and voice your opinion on our community support site!

Urban Turtle has been designed from the ground up to support custom process templates. Out of the box, we provide support for MSF Agile 5.0 (english and french), Visual Studio Scrum 1.0 and Scrum for Team System v3. However, this support is done through the use of what we call configuration mapping files, xml-based files that effectively map Urban Turtle features to your process template specification.

By default, the mapping files are located under ‘C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Access\Web\UrbanTurtle\configuration\project’. I must advise against editing the default files as they are removed when uninstalling the application, such as when upgrading to a new version. If your project is based off one of the aforementioned process templates, I suggest that you start with a copy of one of the default files.

Among other things. creating a mapping file requires you to declare the work item types that should be visible in Urban Turtle, which fields to display and which states to map to each of the columns of the task board. You can also enable certain features such as the recycle bin which requires you to specify the state that corresponds to the Deleted state, if such a state exist. As you can guess, you should have the work item type definitions of the process template handy if you want to go through with this.

While we don’t have formal documentation for these files, their xml nature is fairly easy to figure out, especially combined with the personalized support that we provide via our community support-site or email. We also have a few online resources:

• Configuring Urban Turtle for customized process templates
• Enabling the real-time burndown with MSF Agile 5.0
• Recycle bin feature in a MSF Agile project
• Approval feature with MSF Agile 5.0

To help you get started, here are a few examples of custom configuration that you can play with:

• Microsoft Visual Studio Scrum 1.0 and the Test Case work item type
• MSF Agile 5.0 (english) and the Test Case work item type
• MSF CMMI

If you need anything else, don’t hesitate to contact me. I also invite you to visit our community site where you’ll find answers to commonly asked questions. You can also propose ideas or report bugs. It is monitored very closely by the team.

Back in November of last year, we released Urban Turtle 3.6 which feature major performance improvements. To achieve this, we used a variety of code profiling tools, including Eqatec Profiler. I really liked the straight-forward interface of the product making it simple to compare profiling reports. A few months later, the Eqatec team emailed me to notify Profiler users about a great offer. Put simply, they offered a free Profiler license if I simply requested a trial license for Eqatec Analytics, a tool used to monitor application usage. I didn’t think much of it at first, but have to admit I find it hard to ignore free stuff. Plus, I was really interested in an automated solution to give us actual usage feedback from Urban Turtle users.

I started the trial and was immediately impressed at how easy it was to plug it in the application code base. A few method calls here and there and I was already looking at a web dashboard showing me what features were being used (on my development machine, mind you). I was particularly interested in the feature timings data. With a few more calls, I was quickly tracking how long some features were taking. I was imagining how useful this would be if it were data from actual users. The advantages to using such a tool are just obvious. You quickly know what versions of your application are being used (you all update to the latest version as soon as it is published, don’t you?), and better yet, what features are actually the most popular. This would be so useful when planning out the next releases. It is crazy to think we haven’t had that in the product since the very beginning.

I really enjoyed my trial and we are looking at how to seamlessly embed this in a future version of the application. All usage data would be anonymous, of course, and we are trying to come up with an opt-in/opt-out scenario. We do not want to force anyone to send us this data, and we understand that a server running a TFS instance may not have access to the internet. However, I am now convinced that having such data even from a minority of users would be of tremendous value to us. And I believe that at least a few of us will agree with me and will be more than willing to help us deliver a better turtle, release after release.

Team Urban Turtle is proud to announce the release of Urban Turtle 3.12. During the last month, we’ve focused on further improving support for the Scrum for Team System v3 process template, as well as adding a few template-agnostic goodies for everyone.

Scrum for Team System v3
Implementing support Scrum for Team System (hereafter SfTS for brevity) proves to be an interesting challenge for us. As we strive to protect our template independence, there are many particularities with this template that force us to jump through hoops in order to provide a compelling solution for SfTS users. We’ve introduced the Direct Links query mode in Urban Turtle xx, to support the various link types found in SfTS. We have also added the ability to configure a Sprint work item type per iteration level, to support the Release, Sprint and Team Sprint work item types. Now, we are adding the ability to automatically link these work item types together via the Implemented-By link type, as prescribed by the SfTS guidance.

The default configuration file for SfTS specifies the relationship between the different link types. In Urban Turtle, when you add a Sprint work item to an iteration, it automatically looks up the chain of iterations to find the Sprint work item it should link to. This is all done automatically, behind the scenes, but it requires you to create the Sprint work items in the expected order. This means that you should first create a Release, then a Sprint, and finally, a Team Sprint. Doing so will automatically link the Sprint to the Release, and the Team Sprint to the Sprint, enabling all the cool roll-up features and calculated fields found in Scrum for Team System. To make things a bit easier, iterations without a Sprint work item can now be quickly spotted just by looking at the iteration panel.

We’ve also added the last missing piece in the SfTS feature tracking work item model: the Acceptance Test. This work item type links Bugs to Product Backlog Items but it was missing from the default SfTS configuration file that ships with Urban Turtle. This means that you can now have Product Backlog Items tested by Acceptance Tests failed by Bugs as suggested in the process guidance.

We believe this extended linking support will be more than welcome by current users of the Scrum for Team System process template as they make Urban Turtle a compelling alternative solution to the TFS Workbench from EMC Consulting.

And the goodies!
Most of our current customers rely on the common process templates from Microsoft: MSF Agile 5.0 and Visual Studio Scrum 1.0. If you’re using one of these templates, you can still benefit from the features added specifically for Scrum for Team System, as every new functionality is implemented in a template-independent way. For instance, you can switch to the Direct Links query mode to add support for custom link types. You can configure the relationship between the different work item types to prevent users from adding User Stories to Tasks. Any feature that is unavailable with the default configuration file can be added by modifying your process template and creating your own custom configuration mapping file. But Urban Turtle 3.12 also introduces a few features that work with any process template and do not require any tinkering with the configuration files.

• Ordering of new child items
  With prior versions of Urban Turtle, new child items always appeared on top, with a seemingly higher priority. This doesn’t make much sense for a lot of users as most people tend to create tasks in the order they believe they should be completed. Urban Turtle 3.12 now sets a default backlog priority or stack rank for new child work items at a value higher than the last visible item.
• Improved Pagination
  Experienced Urban Turtle users know that the options in the Cards per Stack menu on the planning board refer to the number of parent or root work items and not to the number of visible work items. This means that you could choose to display 25 Cards per Stack but actually see a lot more work items because all the descendants of each of the visible parent work items would also be displayed. This could severely impact loading times when accessing either board. Furthermore, there was no Cards per Stack option for the task board, as it doesn’t use the stack metaphor.

  In Urban Turtle 3.12, we have decided to change the pagination logic by applying the Cards per Stack selection to visible work items. One caveat to be aware of is that you will always see all descendants of a parent work item no matter how many there are. However, as soon as we hit the chosen Cards per Stack limit, the next parent is pushed to the next stack. This means that it will still be possible to view more than the selected number of work items, but the count should never get unreasonably high.

  We have also ported the same pagination logic to the task board, including the Cards per Stack menu (renamed Cards per Page on the task board). This should also help improve load times as the pagination applies to all displayed work items unlike previous versions which had separate logics for the parent and the Other Work Items sections.

As usual, we recommend that everyone upgrades to the latest version. We are looking forward to your feedback! Please visit our community support-site to ask questions, propose ideas or report issues. It is monitored very closely by the team and you will get timely replies to any inquiry.

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!

Over a year ago, we released Urban Turtle 3.0, the premier Scrum tool for Team Foundation Server 2010. To be honest, it was a bold move. Four months before the release, what we had was a product that almost nobody knew about, compatible only with TFS 2008. We threw half of the code away, went through a complete UI overhaul and developed against beta releases of TFS 2010, aiming to be ready for the big Visual Studio 2010 launch in April. Strong believers in Agile software development practices, we fully embraced the release early, release often pattern and sim-shipped Urban Turtle 3.0 alongside TFS2010. Over the year that followed, we managed to release 12 updates, one each month. Today marks the day of our 12th release: Urban Turtle 3.11. As always, it includes a few new features, several tweaks and improvements as well as a few bug fixes. Read on to find out what’s new!

Print support
Many people have been requesting for some time now that we add printing support to Urban Turtle. As per the Manifesto for Agile Software Development, people highly value individuals and interactions over processes and tools. They wanted to be able to print work items in an index card format for use on an actual task board instead of a virtual one. This is exactly what we are introducing in Urban Turtle 3.11. You now have the option to export work items to a PDF file. We’re starting with basic support, but we do hope you will give us feedback to help us improve this feature over the next releases. Click here for a sample of the PDF output.

Filters on the task board
We have decided to port the planning board filtering options over to the task board following a customer request. You now have the ability to hide work items from child iterations, to hide items that are done and to filter work items according to their work item type. These settings are independent from the planning board, meaning that you can hide done items on the planning board but have them show up on the task board.

Business value on the planning board
Until now, the planning board view was restricted to two customizable fields. Since one of the fields represented the work item title, there was effectively only one field to customize unless you knew your work item Ids inside-out. Customers have requested the ability to view both the Effort and Business Value fields at the same time, for obvious reasons. We therefore managed to squeeze in a third configurable field and the default Scrum 1.0 mapping file has been updated to display the Business Value for Product Backlog Items.

Single Column Headers
Another highly requested feature or improvement regarded the duplicate column headers on the task board. We used to display the headers for every root (or parent) work item, usually the Product Backlog Items. This took up a lot of space and was considered a waste by just about everyone using the product. This has been replaced by fixed column headers which are always visible but displayed only once, saving up precious screen real estate.

Configurable Blocked State
The Task work item type definition in the Scrum 1.0 process template specifies a Blocked field which we added support for the previous release. We used to consider any value as meaning that the item was blocked, but it has come to our attention that this can prove problematic with other process templates. While this option is still available, you can now also configure a value to represent the Blocked state. We have updated the Scrum 1.0 mapping file to consider tasks as blocked when the value for the Blocked field is yes. As with many things in Urban Turtle, this is fully configurable and can be adapted to your own custom process template by editing your project’s mapping file.

There are several other improvements and bug fixes included in this release. I invite you to review the release notes for more information. This release has been driven by your feedback, and we would like to thank you for taking the time to propose ideas, ask questions, report issues and praise us on our community support site. Your help has become an invaluable asset to our development team! As always, we recommend that you download and upgrade to the latest version. We are pretty sure that it has something to like for everyone!