Just a few short months ago, at the Global SAFe Summit in October, we announced the release of a new product capability that enables Planview customers to automatically cost Agile teamwork and subsequently better capitalize Agile software development efforts.
What does this mean, you might ask? Well, our solution uses the powerful combination of Planview Portfolios™ and Planview AgilePlace to roll up and translate team assignments, work time, and work in progress into a consolidated, fully auditable record of actual Agile costs. With this information, Agile and Finance leaders now understand the true impact their Agile teams have to the bottom line, by identifying Agile development costs for proper CAPEX vs. OPEX categorization. Ultimately, this level of information ensures Agile teams get the funding and budgeting support needed for future endeavors and removes the need for manual reporting and reconciliation of time sheets, returning development time back to the business. Cool, huh?
Since this is a game-changing solution and super-new technology (and awesome, I might add), we’ve gathered and collated the frequently asked questions we’ve heard the most – from the SAFe Summit, our annual customer event, Horizons, and many customer/prospect meetings. In this blog, we’ll answer these questions:
- How does this costing Agile thing relate to Agile software development capitalization?
- How exactly do you determine/distinguish CapEx v. OpEx with Planview?
- Why not use story points to determine Agile costs?
- How precise do timesheets need to be (individual, team, or teams of teams) for reporting / capitalizing?
So, let’s get right to it.
Q: How does this costing Agile thing relate to Agile software development capitalization?
A: In the past, capitalization policies have aligned nicely to waterfall phases. There may be uncertainty around how you can think about your capitalization policy in relation to Agile or Lean teams that do not use the classic phase-gated approach to project management.
There is no reason to feel like you can’t capitalize just because you are following a different methodology.
While organizations continue to use waterfall in some parts of their business, other parts of the business have moved to Agile delivery. It’s time to recognize this shift with Finance and figure out how to change the way costing is done. As long as you have a clear policy for identifying which features are eligible for capitalization, capturing Agile costing now translates directly over to capitalization of Agile work within Planview. It’s as simple as having your teams move cards on a Kanban board. More on this below!
While I would love to go into more detail on this particular topic here, I don’t have the wordcount to do so. I recommend reading our eBook to learn more. But, in a nutshell, here’s how we educate our customers how to re-think traditional cost accounting to align to Agile delivery, using Kanban to do so.
Q: The above question usually leads us to this next question: How exactly do you determine/distinguish CapEx v. OpEx with Planview?
A: First, you need to have a conversation with Finance. They will provide guidelines on what features can be capitalized and what can’t.
Using the image above, activities done before development is started (Plan column) are not capitalizable and are booked as expense or Opex. When the overall feature card (that’s tagged as capitalizable) is moved to an in-progress lane, this signals that development has started, and you can start capitalizing the cost (CapEx). Any associated child or story cards are capitalizable, and capitalization stops when the overall feature card is moved to done.
With Planview’s solution, the timesheet filled out automatically, and the capitalizable features and connected stories are categorized automatically, as well.
Q: Why not use story points to determine Agile costs?
A: Well, from our point of view, a point is a representation of complexity, not time or effort. Saying something is a 3-point story does not mean it’s 60% of the effort of a 5 point one. Teams also have different definitions of point values, making it challenging to roll them up across teams.
Q: If not story points, then it has to be manually filled out time sheets, right?
A: No, you don’t need to require people to manually fill out timesheets anymore. Even filling out timesheets every day doesn’t result in the level of accuracy you’d expect. Timesheets are not generally 100% accurate to begin with:
- Daily completion: 66% accurate
- Weekly completion: 47% accurate
- Less than once a week: 35% accurate
Let the teams work on the work they need to deliver to the business and let the time tracking happen in the background.
Q: How precise does time need to be (individual, team, or teams of teams) for reporting / capitalizing?
A: Traditional practices required individuals to fill out timesheets using manual practices that are heavily reliant on the individuals’ memory (see above stats).
Our automated calculation is leveraging the history that is retained from each card’s activity as it’s updated by the team. The result is an auto-populated timesheet that represents what was moved through the Planview AgilePlace Kanban board and delivered. Even if one individual on the team is not as habitual as the other team members, the materiality of effort should reflect the actions across the team.
Automation can still have checks and balances put in place to increase the level of confidence in the data. These procedures may be applied indefinitely or for a period of time until confidence is obtained. Reviewing these options with finance can help establish a process that will work for everyone and all are possible with Planview.
- In high governance environments, the timesheet is auto populated by the natural activity of the team / team member, but the organization may ask every team member to review, sign, and submit their timesheet. In this environment, managers can also review and approve, or the timesheets may be set to automatically approve once signed by the team member.
- In middle-of-the-road governance environments, the timesheet is populated the same way and auto-signed for the team member but may require a team lead or manager to review and approve on a weekly or monthly basis to ensure they’re directionally correct.
- Low (to no) governance environments can auto-populate, sign, approve, and cost the timesheets with no manual review required.
Stay tuned for the next blog as we answer more how-to questions for costing Agile and Agile software development capitalization. In the meantime, take a look at the way Planview’s solution does this automatically in this short demonstration.
