Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Mar 21, 2011 — Enterprise Agile Planning expert

Why Codesion Moved to TeamForge

Enterprise Agile Planning

Trac - Redmine - TeamForge

Over the years, Codesion has used many different open source tools as part of our internal development.  We used Bugzilla, Trac, and most recently, we had Redmine.  As we become better and better at practicing Agile SCRUM methods, we wanted to use a single application that helps us manage all of our user stories, defects, and sprints. This is why we moved to TeamForge (of course being part of CollabNet helped too, but it wasn’t the primary reason we switched).

The Journey

Trac was our very first issue tracker back when we were still CVSDude.  We started using Trac around early 2005.  It was great and fit our needs well.  We had a small team of developers, Trac was free since it was open source, and we hosted it as part of our own product.  We mainly use the Trac wiki and Trac tickets for issue tracking.  It was great.

However, as we added more developers, and our application became bigger, we wanted to have a project concept where a set of tasks is part of a project or sprint.  Trac doesn’t support this.  Therefore, we started to look for another issue tracking tool.

Our search led us to Redmine.  We switched to Redmine in March 2009.  In general, Redmine had several advantages over Trac.

  • Has multiple project support
  • Projects can have sub-projects
  • Easier, simpler user interface
  • Easier configuration of security, project membership, roles, and security permissions

We started using Redmine to manage defects, features, and tasks.  We were also able to break our tasks into different projects.  As a team, we continued to use Trac Wiki since that still met our needs and we didn’t see a need to migrate our content.

As our development team continued to grow, we began to adopt and formalize our SCRUM agile practices.  We began to run sprints, hold product backlog grooming sessions and sprint planning meetings.  We also implemented continuous integration with automated testing of many parts of our code.  We found ourselves using all kinds of different tools, for example:

  • Redmine for defect tracking and some new features
  • Excel for sprint planning, for some product backlog management
  • Codesion WebDrive, Dropbox, Subversion for requirements and design documents
  • Google Docs for real-time collaboration
  • Detailed Requirements and Design Docs are sometimes attached to tasks or defects in Redmine

Our life was now a mess.  We did not have a single place where we could search through all the information and documents.  Our defects and product backlog items were not managed in one place.  Redmine is not the right tool for SCRUM methodology.  In addition, we did not have commit integration between Redmine and Codesion SVN to have ticket syntax integration.

TeamForge to the Rescue

After CollabNet acquired Codesion in October 2010, part of our strategy was to bring CollabNet’s flagship product, CollabNet TeamForge to Codesion – know known as TeamForge Project (TFP).  As part of that process, we began to learn about TFP and its capabilities.

As we did that, we became more and more impressed with TFP’s capabilities.  We were not dictated to use TFP internally, and we want to make sure we used an application that can really make our internal development easier.  Here are some key reasons why we moved to TFP:

  • Single platform for product backlog, user stories, defects, tasks, documents, and SVN
  • Traceability across all these items
  • SCRUM methodology simplified

Let me explain each of the above points in detail.

Single Platform

With all of our artifacts in one platform, whether it is a defect, user story, or documents, they are all now searchable in one place.  We no longer need to go to different places to search and find items.  TFP provides a versioned document repository to store documents.  Microsoft Office documents are integrated with TFP so that you can edit a word doc and save the latest version into TFP.

We now have all defects, user stories, and other tasks all in one place.  That way, when we are doing a sprint, all defects, user stories, tasks are prioritized in the same sprint, visible across all team members.

Finally, the single platform gives us the traceability that we need.


TFP has the capability to associate any object in the system with another object.  For example, if you have a detailed design document in the document repository, you can associate that document to a user story, which is useful.  As you update the document, the latest version is associated with the user story.  Codesion SVN is also integrated with TeamForge.  You can commit your messages and update any artifact within TFP.  This is powerful because as our developers annotate what is happening in the source code, it updates user stories or defects in which scrum masters and product owners can have visibility into what is happening.

In addition, we started to track remaining effort within TFP.  This allows us to have a graphical view using the burn down chart to quickly find out how our sprints are doing.

Burndown Chart

SCRUM Simplified

Now that Codesion is on TFP, it has greatly simplified our SCRUM management process.

TFP can support many methodologies due to its flexible tracker where you can create custom fields and use planning folders.  I categorize and organize our artifacts into planning folders with the following taxonomy:

Product Backlog
– Billing
– Platform
– Git

– Sprint 2/2011
– Sprint 3/2011

Any product backlog item will go into the appropriate planning folder.  At the product backlog folder level, I can see all of the product backlog items.

Product Backlog Grooming Session & Sprint Backlog

During the Product Backlog grooming session, we determine what backlog items we should prioritize for the next sprint and we create a new Sprint planning folder, Sprint 4/2011. We drag-and-drop prioritized backlog items into that sprint and rank the priority of each item (my favorite TFP feature). Then, the team provides input regarding level of effort via story points.  After that, the team commits to how many story points they can tackle in the next sprint and, based on stack rank and story points, we arrive at the final set of backlog items for that sprint.  This is now our Sprint Backlog.

Sprint Planning

Once the Sprint Backlog is in place, the team goes into Sprint planning.  Because TFP offers parent and child dependency relationship, we create sub-tasks and further sub-tasks, within a backlog item.  We create a defect that is a child of a specific backlog item.  The parent backlog item can then sum the remaining effort of all child objects for tracking purposes, which is a great feature.  We now have visibility of all the tasks and defects, all in one place, one view, of a particular backlog item.  I typically stack rank the mix of defects and tasks accordingly, a powerful feature letting my team know exactly what item to work on next.


Codesion has always believed in using the best and simplest tool for your needs.  Trac and Redmine had been our simple, easy to use tools for quite awhile, and they worked wonderfully.  In fact, we are still using Trac wiki today.  However, as our team grew and our requirements for better Agile SCRUM tools grew, TFP has been a powerful tool that enables us to collaborate more effectively.  Now, all team members know exactly the stack rank priority of defects and user stories.  We have a clear, easy way to track the remaining effort as we move through the sprints.

In the future, we hope to integrate our Continuous Integration processes into the mix and bring that into our product offering as well.  Stay tuned…

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us