Michael LoCiceroDirector of Software Development| Trillium LabsSecaucus, Nj, United States
Hi everyone,
One of my software development teams is using Agile Kanban methodology, as we both support a Production product while also developing new features. That said, the kanban approach works well for us as we prioritize a stream of work on our "todo" list, but also in conjunction work longer-term projects which revolve around adding new features or services. The flexibility of Kanban is helpful to us, rather than having fixed sprints/deliverables.
I've been thinking about a process improvement to keep the team focused on the right thing, which is adding business value to our customers. We do this implicitly, but I think it would be helpful to formalize the metric and our business stakeholders would also appreciate it. That said, I'm thinking about building a dashboard report the team(and our stakeholders) can analyze every two weeks or so. One of the metrics I'm thinking about using is Business Value, which is essentially just a number that our team will choose based on the feature. I'd like to see our BV output, as well as metrics on how many bugs, customer questions, data issues, etc we have every couple of weeks. I'm thinking the team could use this to keep ourselves honest and determine if there needs to be improvement in one area or another.
Would love to have some feedback from the community on this one. The reason why I put the subject as "you get what you measure" is if we decided to measure something meaningless like tickets completed every two weeks, well that's what we would get, more tickets. But at the end of the day that doesn't necessarily mean more value for our customers. That's why I like using a BV metric, which would be set by a room of stakeholders(developers, technical account managers, stakeholders, etc).
Thanks everyone!
-Mike Saving Changes...
Sort By:
Alan BergsmaDirector of Project Risk Management| ALB ConsultingParadise Point, Qld, Australia
Hi Mike,
Without knowing the specifics of your project, I only offer general suggestions.
I suggest measuring three things:
1. The total amount of time that a customer spends on the system on an end-to-end process (this is the total amount of time that your customer spends filling in forms, reading instructions, etc.) e.g. a customer may spend 300 seconds in submitting an application.
2. The total amount of time between the start of a process and the end of a process (including any steps one of your business users needs to complete) e.g. it may take 5 business days between when a customer submits an application to when they get an approval/rejection/request for more information.
3. The total amount of time that your business users spend processing an end-to-end process (this is the total amount of time that your business users spends assessing, filling in forms, etc.) e.g. 3 business users from 2 departments may spend 10 minutes in processing an application.
Tip: if you want to minimise the total time it takes for an end-to-end business process, look to minimise the number of business users required in the process (i.e. minimise the number of times your process flows cross swim lanes).
Measuring business value can be a little tricky. The reason for this is because delivering a product or service doesn't necessarily add actual business value - it creates the potential for value. You can have a baseline - the value the business expects to get from what is delivered. Then people have to use what was delivered. Somebody has to track the actual value realized from using what was delivered, which can involve intangibles (i.e. difficult to measure), in order to begin identifying business value from what was delivered. This is assuming you can separate the results from other changes and things that have been delivered.
I think this is part of why people focus more on measuring how well they do what they said they would do. It may not add business value, but you can measure it. You can use it to show that you're improving, or identify areas where you need to improve.
Using the triple constraint as an example, you can deliver a project on or ahead of schedule, on or under budget, and meet scope requirements, but the product or service delivered can still fail to deliver business value for reasons that have nothing to do with the project, and it may take months, or more, to realize that it is failing to deliver. All you've delivered was potential. You can report on that potential; I think that's pretty common. But, is it really meaningful?
But, this doesn't really answer your question. If your intent is to use reports to manage perception, you're probably on the right track. Work with your stakeholders to determine what is meaningful to them and report on that - system availability, turnaround time on different priority/severity level bugs, bug:enhancement ratio, reported vs completed bugs, requested vs delivered enahncements...
Before you look at what to measure, identify what BV means at your company and how your organization contributes to that definition. If all you're delivering is the potential to realize BV, look for the measures that are the most meaningful to your stakeholders. Saving Changes...
Community Champion
