Skip to content

Think T-Accounts: Agile Adoption on Microsoft Dynamics Projects

You can use accounting T-Accounts to communicate one of the main agile principles to stakeholders on Microsoft Dynamics projects. “Satisfying the client” is agile principle number 1, and deployment teams satisfy the client by delivering business value to stakeholders on projects. The client’s product owner is the guardian of the business value, represented by user stories.

Image of eyeglasses and financial papersMuch of the time on Microsoft Dynamics projects, it is the CFO or controller that is the executive sponsor. Therefore, it makes sense to use accounting analogies to communicate the reasons for using agile principles when managing Dynamics projects. When conceptualizing the Agile T-Account, think of “story points” as a revenue account with a normal balance on the right side of the T-Account and think of “hours worked” as an expense account with a normal balance on the left side of the T-Account. When running a successful businesses you want maximize business value by crediting the “story points” revenue account while minimizing debits to the “hours worked” expense account.

Let’s create Agile T-Account examples by using real life sprint data as shown on a Rally Software burndown chart. Rally’s burndown chart shows the burn-up values for user stories in green, in addition to the burndown values in blue for the sprint’s activities. The higher the green bars go to the right at the end of the sprint, the greater the story points and business value delivered. The lower the blue bars go to the right, the less work that needs to be performed.

Image of Rally iteration burndown

This burndown chart shows that 1,000 out of 1,142 story points were accepted by the client product owner by the end of the sprint. This translates into about 88% of the sprint’s planned business value being delivered. In this sprint the product owner did not approve all the user stories as being complete. In other words not all the planned business value was delivered to the client by the end of the sprint. The burndown chart also shows that there was no remaining work to be performed at the end of the sprint. Essentially, 100% of the planned work was executed by the end of the sprint. In summary, all the planned work was executed, but not all the results were satisfactory to the client.

Image representing iteration burndown as a T-account

Translating the burndown chart into a T-Account format we would record a debit transaction of 88 to the Story Points revenue account, and we would record an offsetting value of 88 to the Project Asset account. Recording the expense side of the transaction we would show a debit transaction of 100 to the Hours Worked expense account and we would record an offsetting value of 100 to the Project Liability account.

Ideally, I would want my delivered business value to be equal to or greater than the cost of delivery. As an accountant looking at the T-Account examples, I would quickly understand that my project is not doing well; the cost of work is greater than the business value delivered. I would not be satisfied with the results of this sprint.

Blog Tags: 
Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube