Let me start by saying I hope you never have to use this approach in your organization. If you have buy-in from your senior staff, your teams, your PMO, and your stakeholders and customers on your process and how it is measured, read no further. If not ask yourself this…
Does your company live and die on metrics? Are you part of a process transformation that is having a difficult time dealing with some of the aspects of a switch to iterative development, namely planning and prioritizing according to the ever-changing needs of stakeholders vs. adhering to a highly detailed project plan? Is having a living, breathing iterative plan causing your PMO to nearly short circuit?
Well here is something you might want to try to help your PMO keep consistent with their charge of product process monitoring and do so in a way that supports your iterative transition. It’s not standard Scrum, XP, Lean, or any other Agile practice, and some may argue (justifiably so) that it’s Water-Agile of some flavor and that it detracts from the entire iterative experience. But in some cases it could help PMO’s in large organizations transition with you over time. The PMO and organization will still need to understand that value assigned to a request (story, use case, group of requirements, etc.) is stakeholder-defined so any metrics coming from this view is heavily weighted on a specific (but critical) group of people surrounding the product being measured and is only good for measuring the progress of the product against itself and not against other products. However, organizations new to iterative processes, having this process in place does require the establishment of a team of stakeholders who are responsible for defining and prioritizing value against all requested work. This can be beneficial as often times organizations new to iterative development skip over this part of the process which can be extremely detrimental to the success of the team and the product. If your PMO is tracking this, its simply a form of governance that ensures a critical part of the iterative process is in place and being executed.
What is the value of calculating your Value-Output?
Value-Output information can be used as a metric to gauge how well your process is tuned to achieving what you intend it to achieve and how well (loosely) you are performing within the process.
What is Value-Output?
The amount of value provided by executing a defined process per a specific unit of time
By setting a benchmark you have a starting point to gauge what is being produced today. Once the benchmark is established, you can now augment your process and gauge what effect it has had on VO. Remember, the definition of “VALUE”, how it is assigned, and when it is allowed to be counted as output needs to be established before any of this can be of any use.
The definition of “What is Value-Output” suggests that there is a measurable rate at which value is provided by executing a defined process. In equation format it looks like this:
VO = Sum (V1…Vn) / UT
- VO = Value-Output
- V = Value
- UT = Unit of Time
Experienced “Scrummers” will recognize this calculation as velocity which is the rate of work delivered a sprint team achieves over a certain timeframe. This same calculation can be used to gauge value delivery in the same manner by replacing the size of the functional request with its value (keeping in mind that value is determined relatively by stakeholders close to the product just as story points or work hours are determined by development teams).
To find your VO value, calculate the sum of the value you are providing per Unit of Time standard you are keeping (relative or absolute). For example, an agile team may use iterations as their UT, and Value points per story as their V. You can apply whatever units you are using in place of the agile ones if you are not agile. For example:
One Iteration Calculation of VO: 47 = Sum (13,13,8,5,3,2,2,1) / 1
Three Iteration Average of VO: 43 = Sum (13,13,8,5,3,2,2,1,13,8,5,3,2,1,13,13,8,5,5,3,3) / 3
In order to do these calculations several things must be known:
How is value represented?
Value is represented in a standardized set of relative units
How is value assigned?
Value is assigned to a functioning software unit (story, use case, group of requirements, etc.) and is assigned by a committed group of representatives who have a stake in the outcome of the process being valued
What counts as value?
Value is counted as output when a functioning software unit (story, use case, group of requirements, etc.) is delivered within the unit of time being measured and meets or exceeds all requested functional criteria without negatively impacting any existing component critical to the intended functional and non-functional design of any request (Non-function design in this case could represent KPIs, security, accessibility, availability, and so on.)
As you can see, whatever process you are following, you still need to know how value is represented, how value is assigned, and what counts as value in order to establish this performance metric. If you cannot do that today, measuring the effectiveness of your process in achieving its intended goals will be difficult to identify once you have improved to a certain point. After all, being able to identify changes in your output at a more granular level and consequently identify the reasons for it is what allows a group who is performing good to become a group that consistently sets the standards in performance.
However, none of this is a replacement for the best measurement of performance…timely deliveries of working software and highly impressed and satisfied customers.