The closer you get to the board level of (or any executive level) in an organization the more interest there is in answering the question “Where are we spending our money?” Executives are not interested in looking back on a report. Rather they are trying to understand whether the organization is using money wisely when looked at from the different perspectives that they have.
For organizations, the process is similar to those personal finance “spreading reports” you get from credit card companies at the end of the year. You may be surprised at how much money you have spent on “Alcoholic Beverages”, but the real question you ask yourself is “should I be spending less (or more) on this category?”
While many Agile-ists just want to say “Trust us; we are working on the most important thing every time”, this really is not responsible management from the perspective of the executives, nor sufficient for good corporate governance. The reason is that there are many different perspectives of the use of money that need to be looked and there is no (single) way of determining priority that would take into consideration these multiple perspectives.
In addition many organizations assume that the work management tool we are using to track work can be used to directly replace existing time tracking systems. In most cases this is not true. While we can generate the answers to questions such as “where are we spending our money?” using Agile data, we do not have to know “how much time did a particular person spend on this” to answer the question.
Organizations typically need to see their work from multiple different perspectives or dimensions. Organizations generate these reports / charts using these different perspectives, each repressing 100% of a particular dimension. The data is most useful when it shows trends over time for a particular dimension, as opposed to a single point in time.
Here are some dimensions I’ve seen organizations track:
Organizations will often be interested in how much they are investing in different time horizons of a product / solution. Are we investing the right amount in evaluating new products, in comparison to retiring existing products. Example tags (using standard SAFe discussion) on (for example) Epics might include:
Organizations often want to understand what kind of decisions we are making at what kind of levels. For agile transformations, there is a desire to de-centralize decision making as far as possible. An example tag on Features to track this might include:
Organizations often want to understand how the capacity used maps back to the strategic themes of the organization. For example, you might see tags on Epics that reflect:
Organizations often need to understand whether they are heading in the right direction for an initiative well before the customer realizes the value. This often means identifying leading indicators, metrics that we believe means that if they head in the right direction, the outcome to the customer will be realized. Tagging Epics to reflect these indicators could help with calculation.
Organizations typically operate out of two budgets; a capital budget and an operating budget. If it comes out of the capital budget, then we can defer the recognition of these costs until we actually start selling the result of the effort. If it comes out of the operating budget, the costs drop straight to the bottom line affecting your profitability immediately. Tags we could apply to Features could simply be:
See How Do We Do Software Capitalization When we Go to Agile? for more on this subject.
Often the work that is being taken on is the result of a customer project, for example. Project Managers and other stakeholders will be interested in understanding, for example, progress on elements of their project. Typically some kind of unique Project ID is used to isolate projects from other projects, as well as work that is not related to any project.
Organizations often have different sources of funding for an IT organization and it is up to the IT organization to ensure that the capacity allocated to work lines up with these funding sources. To track, we could tag based on:
The Kano Model of Customer Satisfaction classifies needs, capabilities, or product features based on customer’s perception and their effect on customer satisfaction. These classifications are useful for guiding design and investment decisions in that they indicate when good is good enough, and when more is better.
Kano analysis helps people understand how features stack up to support customer satisfaction. Customers (or their proxies) respond to questions related to their needs. This data drives the analysis. Using Kano analysis you can determine whether, for example, a feature is a “must have” or a “differentiator” which would then also indicate the level of investment you might apply to this (if “must have” you might choose to apply minimal investment to get the feature, allowing more investment in something that truly excites the customer - the differentiator.)
Tagging with the Kano model attributes helps us determine whether we are really going after something that excites the customer. Sample tags might include:
For more information see Kano Model
One product development shop I worked with really wanted us to track truly innovative work separately from maintenance work. Their categories were a combination of a number of notions:
You can see that this list is a mix of a number of the ideas above. The problem people have with this type of categorization model is that it is often not clear which category an item belongs to, causing confusion. This approach is generally not recommended.
There are two general approaches used by agilists everywhere:
Different tools will support different approaches. Often a combination of approaches is also used.
No matter the approach, we’d provide tools and dashboards to people so they can easily find data that was not tagged appropriately so the data can be cleansed.
Some organizations feel like that they need to get very precise with these categories. So for a particular category, for example Capitalization they won’t just label a feature with “Capital budget” or “Operating budget” but rather will try to estimate a percentage of the Feature that fits into each category (eg Feature is 33.3% capital budget, and the rest operating).
In general, I recommend against this approach for a number of reasons:
There are two basic units used by agilists to track proportions of investments:
In most cases it doesn’t really make a lot of difference what is used. In general I’ve found that a count approach is both simpler and more consistent over the long term. Most organizations are more comfortable using size because this seems like it is an important factor. The reality is that the “law of large numbers” takes over for large implementations so the counts are “good enough” and probably about the same as using size information.
A word on getting started on Agile reporting approach. Initially it is difficult for organizations to understand how you turn points and counts into dollars. See How Do I Convert Points and Velocity to Dollars? for the general approach.
And then many people worry that tracking counts of epics, features, and stories, or epic, feature, and story points are less accurate than traditional time keeping systems. Experience shows that the data from these agile systems is in fact more accurate because, unlike traditional time card systems, the people doing the work actually have an interest (skin in the game) when it comes to count or point data. For more information, see Can We Trust Story Points as a Measure of Effort?.
And finally, I’ve found that from a practical perspective you will have to run time keeping and point systems in parallel for a period of time so that people can get comfortable with the new approach.
Context matters. This page was written out of the following context: