One of the first questions we get when implementing and training agility in organizations is about accounting. So much of what happens in an organization revolves around the numbers -- risk/reward, investment/return, burn-rate, etc. Many times developers and technology management gets wrapped up in all the goodness of change and then we forget to bring the accounting folks along.
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