In a lot of organizations, you can get away with glossing over some accounting principles because the project has a charter and a budget that is independent of the way the project is ran. However, it's totally natural for accountants to want to see inside the project as much as possible. And once you start running multiple projects in a program a lot of this hidden detail raises it's ugly head.

We wrote an agile project-tracking tool last year as part of an effort to provide some answers to these questions for a large corporation that was looking to have more control and insight. While it's not publicly available, we did learn several lessons that might be useful to others.

So if you're trying to figure out how accounting concepts apply, here are some terms and their meanings in accounting terms:

• Story - This is the smallest measurable unit of work from an external standpoint. It represents some piece of solid business value
• Sprint/Iteration - This is the smallest unit of spending from an external standpoint. It represent all of the team members working for a fixed period of time, usually 1-8 weeks. By working in fixed timeboxes, with regular releases of value back to the organization, teams shorten their feedback cycle (suspense) and get into a rhythm of work
• Backlog - This is the work queue of work allocated to the project. Work can be in big chunks or small chunks. It is not necessary until work is allocated to a sprint that it be broken up into the smallest business-valued chunk possible. In fact, premature chunking can lead to large, unmanageable backlogs
• Task - Once a story has been allocated to a sprint (iteration), many times the team or developer will want to break it down even further into smaller to-do items that do not necessarily have direct business value. This is an internal project technique and should not be visible to external stakeholders. Tasking techniques and practices can vary by team, individual, or sprint. Sometimes teams will have estimated hours associated with tasks. This allows them to track (internally) work being accomplished inside of an iteration
• Information Radiators - Agile teams use various visible charts, graphs, cards, post-its, etc to show and track team performance. The idea is that anybody in the organization can walk into a team's collaborative room and see exactly what the status of the entire project or current sprint is
• Burn rate - Agile teams burn money in chunks divided by sprint. If 5 team members have an average loaded rate of 50/hour and work in 2-week sprints. The burn rate for the team is 50 x 5 x 40 x 2 = $20,000.00/sprint. Agile theory says the project can be canceled at the end of any sprint if necessary. Since the team is delivering business value back to the organization for each sprint, and since the backlog is prioritized in terms of greatest value to least value, in theory the team should be delivering the pieces with the most value first. This allows projects to be canceled quicker (although some functionality is typically left undone)
• Product Owner - This is the representative from the business to the team
• Work Prioritization - Handled by the product owner. Sometimes technical considerations come into play with work prioritization. This is a discussion that the team should have. But the final decision-maker as far as prioritization of stories in the backlog is the Product Owner
• Estimation of backlog size - The team is responsible for estimating the size of items in the backlog. This estimation should be redone during the planning time for the next sprint., There are various methods for doing this
• Estimation of total cost - As the team continues to deliver tested chunks of business value back to the organization during each sprint, an average velocity is created. From this it is possible to estimate how many sprints it will take to complete the backlog (or to meet a certain release point). There are various methods for doing this, and, like other estimation processes, it should be redone as part of sprint planning. In general, estimates are very bad for the first few sprints and get progressively better as the project continues
• Story Points - An arbitrary measure of relative complexity of delivery for stories. They have no units and are not fungible from project to project
• Requirements/Analysis/Design/etc - These traditional terms and skills from technology development do not disappear from agile teams, rather they exist alongside agile concepts. However projects are not planned or managed from these traditional concepts. For instance, Earned Value Management systems (EVM) need to be significantly re-thought in terms of agile concepts. Likewise Portfolio Management Systems

   

Accounting and agile project management are not naturally enemies! Even though it can seem so. PMI and accounting principles still apply, although you need to be less rigid in how you understand and use them.

Unfortunately, we're not at a point where we can just roll out tools and lay down the Ten Commandments as to how things are going to work. In a world of SarBox and CAP, agile is the new kid on the block. That doesn't mean it won't all work together -- but it means that it's going to take some work to make it happen.

About the Author

Daniel Markham is a hands-on technologist, agile coach, and writer. Some of his clients include State Farm, Pitney Bowes, Charles Schwab, Ford Motor Company, and the Department of Defense. His agile consulting business, Bedford Technology Group, works with clients worldwide to create hyper-performing teams. He is a pilot and scuba diver, and lives with his wife and 2 children in Bedford, Virginia. You can reach him at [email protected] or follow his blog at www.whattofix.com.