This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
From VersionOne Customer to VersionOne Employee – Part 2
In my last post I talked about my former role as a VersionOne customer and some of the challenges we faced with waterfall development. I outlined how we selected VersionOne to solve some major collaboration issues and the professional services that helped get our teams up to speed with our new agile project management tool. In Part 2, I will dive deeper into how VersionOne organized our agile process.
WE CONTROLLED OUR AGILE PROCESS, NOT THE TOOL
What I liked about VersionOne over other tools out there is that it could be implemented to fit our agile process; we didn’t have to change our process in order to fit the tool. Through VersionOne we could organize our backlog of user stories and defects with the Excel Import option. This is great for companies with an existing backlog. The items can be added to an Excel template, and then imported directly into VersionOne. Once there, the tools to rank and organize your backlog can be as simple as drag and drop for single items or more advanced such as multiple ranking and feature grouping. This video highlights the ways to create and organize your backlog.
And now that we had a proper backlog, VersionOne gave us insight into what the team needed to do to complete a sprint. Through the fields in the backlog items and defects, we were able to provide acceptance criteria in a recognizable format, apply story point estimates and outline tasks and tests. After a few sprints we captured velocity and were able to get a good understanding of how much work the team can handle by looking at the average velocity through the Velocity Trend Report.
Things were going well with my team and our agile approach, but now it was time to scale from one team using agile to five. We had five teams working different product lines with essentially their own backlogs. VersionOne’s use of the project tree allowed us to create separate projects with their own backlog but still give product owners some visibility on other teams’ backlogs. This was useful in cases where there was integration work between teams.
For teams evaluating VersionOne there’s plenty of support available in the early stages of adoption to set up the proper project structure. This is key to being able to provide the correct level of reporting, all the way from the sprint to the program levels, and ensure that the backlog is correctly ranked and organized among the projects.
Check out the few ways you can evaluate VersionOne here and see if the tool is a fit for your organization.
Do I miss testing? I’ll be honest, no. But I do miss the joy of completing a successful sprint with my team and the rush we’d get from producing something valuable. Teamwork is everything.