It occurred to me recently how much emphasis is put on the need for an Agile Project Management tool as you begin to adopt and expand the use of Agile in your development environment.  While many, including myself, would argue that using post-it notes and physical story boards are the best ways to start and Agile pilot team (since I believe it instills good habits, like circling the team around a common goal) there is certainly a place for Agile Project Management as you begin to expand Agile within a larger organization.  Agile Project Management provides visibility across the development lifecycle and into teams spanning multiple time zones, allowing for a big picture view of the project.

User Stories are the Key

Driving development through the use of User Stories is often considered a determining characteristic of whether a shop is considered Agile or not.  And while I won’t go into the details here, it is important to have a ‘place’ to manage those user stories in a backlog.   It’s also important to be able to see and report which iteration the user story is assigned to, and the current status of a particular story.  Has it been scheduled for an iteration?  Have we started development on it?  Who’s working on it? Etc…

Understanding the state and status of user stories that are in development is crucial to accurately reporting the current state of an iteration as a whole.  If you are going to use burndown charts to know how many hours of work are left for an iteration, or a burnup chart to determine how many points are left to be accepted for an iteration, you are going to need accurate information.  Accurate data comes from updating user stories and tasks on a timely basis so you always have the freshest information.

How Accurate is Your Information?

One aspect of user stories that is often overlooked is the linkage between the user stories within an active iteration and the location of the actual code changes for those particular stories.  If you only have an accurate view of the stories from a development standpoint, but you have no idea where the code for that story is, then all of the information in your project management tool contains incomplete data.

Under more traditional development methodologies, the time to ‘check’ the linkage between closed issues and code that was changed in order to complete said closed issues happens on an infrequent basis.  Checking the linkage usually occurs toward the end of a long development cycle, when teams are getting close to a release point.  If we are executing on a 6 month release cycle, it probably won’t occur until 4 months in.

Identifying the status and locating the code for user stories happens weekly on an Agile team, regardless of the iteration length.  This requires you to have quick access to accurate information to track those stories from a development perspective.

Accurate Information… Quickly

In many traditional SCM systems, developers must manually indicate the linkage between the code and the story it is associated with as the code is checked in. At the end of the iteration, teams must determine what stories are fully completed and what stories are only partially done, and need to be retargeted to the next sprint.

Traceability and visibility into each story is necessary to see where code changes are located. The ability to easily associate code modifications with a user story will eliminate error prone manual linkage problems. In AccuRev, this information is stored in a Change Package, or a deep linkage between the user story that is related to project management and code. Change Packages can be tracked through the development cycle.  This gives developers visibility into the status of an individual user story without additional overhead, while providing traceability to Scrum Masters and Product Owners into the status of an iteration with increased accuracy.