This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Why Codesion Moved to 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).
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.
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.
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:
– 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.
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…